sebb a écrit : > On 22/05/2009, Phil Steitz <phil.ste...@gmail.com> wrote: >> 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 >> >>> Any volunteer to do this rather boring work ? >>> >>> > > I can make a start on it. > > I suggest that the implementations are flagged (e.g. with TODOs) until > the serialization implementation has been checked and documented. > > WDYT?
It sounds good. Many thanks. Luc > >> 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
