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