commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <billwbar...@verizon.net>
Subject Re: [math] Serialization
Date Mon, 25 May 2009 23:32:35 GMT

----- Original Message ----- 
From: "Luc Maisonobe" <Luc.Maisonobe@free.fr>
To: "Commons Developers List" <dev@commons.apache.org>
Sent: Monday, May 25, 2009 12:39 PM
Subject: Re: [math] Serialization


> 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.
>

You should see the mess Phil caused in stats ;).  Almost (or more likely 
all) of the classes under stats and subpackages look transient to me (e.g. 
why would anyone want to serialize Kurtosis?).  But again, want to ask 
advice before going terminator on those packages.  IMHO, we'll need to write 
junit tests for the ones that we leave Serializable, since I already found 
(and fixed) two classes in linear that couldn't be de-serialized.

> 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
>
> 


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


Mime
View raw message