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" <billwbar...@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.maison...@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 >>>>>> <billwbar...@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-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
