On Tue, May 08, 2012 at 01:22:38PM +0200, Sébastien Brisard wrote: > Hello, > > 2012/5/8 Thomas Neidhart <thomas.neidh...@gmail.com>: > > On Tue, May 8, 2012 at 12:24 PM, Gilles Sadowski < > > gil...@harfang.homelinux.org> wrote: > > > >> > I am in favor of this second option: add Serializable were needed upon > >> > > request. > >> > > >> > +1 > >> > > > > +1 > > > > > >> > > In this case, the request seems fair as the class is mainly a > >> > > simple container for two values. > >> > > >> > But what ever the size/complexity, adding Serializable needs to be > >> > done carefully, and documented as necessary using @serial, > >> > @serialField, @serialData tags. > >> > >> > > > >> I am _not_ going to work on that. [Plenty of arguments given previously > >> saying exactly that: it must be done seriously. It is not so in CM. And > >> (IMHO) it is not necessary for CM to support "Serializable" (also argued > >> previously).] > >> > >> > Just adding "implements Serializable" is a bad idea. > >> > >> Agreed. > >> > >> So? [I guess I'm not going to do anything myself on this issue.] > >> > > > > I think we should implement it where it is requested and makes sense (like > > results of a computation). But then in a proper way (should be defined in > > the developers guide or even the wiki as best practice to follow). > > For other cases we can just skip it, but please, do not remove Serializable > > just because you don't like it (as it happened in the case for the > > referenced issue). > > > > Thomas > I have mixed feelings on this issue. I guess that everyone agrees that > serialization must be done properly. Like Gilles, I'm not going to > work on this issue, probably for other reasons > 1. I certainly do not have the required expertise (and do not have the > time to acquire it at the moment). Which makes me wonder about > maintenance of serializable classes. Committers like myself reviewing > other people's patches on serializable classes, might well be > innocently committing a patch which should not be. To prevent that, we > should make sure that we do have some "serialization referees" in the > CM community, which might overload these people.
+1 However because there are no such referrees, support of "Serializable" should be ruled out. > 2. I think there are many more urgent issues (only my opinion, > though), like the open issues about precision in the distribution > package, or the implementation of more special functions, which is a > quite time consuming, but necessary task. +1 One of the previous arguments: CM is a collection of (math) algorithms rather than data structures meant for exchange outside of CM itself. Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
