commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [math] Serialization
Date Mon, 25 May 2009 19:39:11 GMT
Bill Barker a écrit :
> Ok, most of the rest look like transient classes (e.g. all of
> linear.decomposition).  So asking for what needs to be Serialized, and
> what doesn't.

As the main developer of the decomposition package, I can say the
reasons for having these classes Serializable are the same bad reasons I
had for all the other ones ... So as far as I am concerned you can
safely remove Serializable for all these interfaces and also for the
implementation classes.

Sorry for having caused such a mess.

Luc

> 
> ----- Original Message ----- From: "Bill Barker" <billwbarker@verizon.net>
> To: "Commons Developers List" <dev@commons.apache.org>
> Sent: Saturday, May 23, 2009 12:13 AM
> Subject: Re: [math] Serialization
> 
> 
>>
>> ----- Original Message ----- From: "Luc Maisonobe"
>> <Luc.Maisonobe@free.fr>
>> To: "Commons Developers List" <dev@commons.apache.org>
>> Sent: Friday, May 22, 2009 4:19 AM
>> Subject: Re: [math] Serialization
>>
>>
>>> [I changed the subject to help follow the thread]
>>>
>>> Phil Steitz a écrit :
>>>> Luc Maisonobe wrote:
>>>>> Ted Dunning a écrit :
>>>>>
>>>>>> In favor or not, Serializable shouldn't in in widely used interfaces.
>>>>>>
>>>>>> As an example, a Lucene index is a reasonable implementation of a
>>>>>> sparse
>>>>>> matrix.
>>>>>>
>>>>>> Would you require that I have to figure out how to make it
>>>>>> serializable just
>>>>>> because I declare it as a Matrix?
>>>>>>
>>>>>> Do you imagine that most developers will do more than just punt in
>>>>>> such a
>>>>>> situation if the interface absolutely requires that the object be
>>>>>> serializable?
>>>>>>
>>>>>> Leave it to particular implementations to be serializable or not.
>>>>>> Please,
>>>>>> please, please don't force it into the contract for all
>>>>>> implementations.
>>>>>>
>>>>>
>>>>> So we have reached a consensus: remove Serializable from interfaces
>>>>> and
>>>>> push it down to implementations only.
>>>>>
>>>> +1
>>>
>>> There is one interface at least for which I ask to retain Externalizable
>>> (not really the same as Serializable, but in the same spirit). It is the
>>> StepInterpolator interface in the ode.sampling package. Externalization
>>> for this interface is a desired and important feature used for example
>>> in the ContinuousOutputModel class. The interface is not intended to be
>>> implemented by users, and in fact even the class implementing it are not
>>> directly visible by users: instances are directly built by ODE
>>> integrators (each integrator has its own interpolator).
>>>
>>>>> Any volunteer to do this rather boring work ?
>>
>> I can take a stab at it (but may have fewer spare cycles than sebb).
>>
>>>>>
>>>> I wish I could say yes, but I am running out of buffer space atm ;)
>>>>
>>>> Phil
>>>>>
>>>>>> On Thu, May 21, 2009 at 8:20 PM, Bill Barker
>>>>>> <billwbarker@verizon.net>wrote:
>>>>>>
>>>>>>
>>>>>>> - I *strongly* urge you to remove Serializable from everything!
>>>>>>> Please, we
>>>>>>>
>>>>>>>> did this in MTJ and it turned out to be a major pain. A more
>>>>>>>> appropriate
>>>>>>>> approach is to define a class for reading/writing Matrix
Market
>>>>>>>> files.
>>>>>>>> This
>>>>>>>> can be a new feature in 2.1. If you're going to leave it,
at least
>>>>>>>> document
>>>>>>>> that the Serializable form is not guaranteed to remain compatible
>>>>>>>> across
>>>>>>>> versions.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Like Luc, I'm generallly in favor of Serializable.  Since some
of
>>>>>>> the posts
>>>>>>> on this thread have suggested problems with the current
>>>>>>> implementation, I'll
>>>>>>> try and run some tests over the (what is here, long) weekend.
>>>>>>> Again, no
>>>>>>> consensus so not doing anything immediately.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message