commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] Serialization
Date Fri, 22 May 2009 11:19:56 GMT
[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 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
>>> <>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:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message