commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gil...@harfang.homelinux.org>
Subject Re: [Math] Serializable (again)
Date Tue, 08 May 2012 11:44:21 GMT
On Tue, May 08, 2012 at 12:51:28PM +0200, Thomas Neidhart wrote:
> On Tue, May 8, 2012 at 12:24 PM, Gilles Sadowski <
> gilles@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).

Sorry to correct you: It was removed because it was not implemented
properly. As a matter of principle, it is better to not support something
rather to give a false sense of what can be done with the code.

Of course, you are welcome to work on this functionality if you want to add
proper support to CM.

I started this thread with the same question as was pending from the last
time this issue was raised: What policy do we settle on?

For the moment we have (IIUC):
 * proper support: Sebb, Gilles
 * "sloppy" (no judgement implied ;-) implementation: Luc

If proper support is selected, then any attempt to introduce "implements
Serializable" that falls short (e.g. missing tags as reminded by Sebb, and
unit tests[1]) should be vetoed.

Please note that, as argued previously, sloppy support can be easily handled
by users of CM.  My opinion is that we should not decrease the quality of CM
just to spare lazy ;-) users a couple of lines in their own code.
[And also note that users whose application really relies on serialization
should probably get the support from a dedicated library...]


Best,
Gilles

[1] Which must be ready to prove compatibility across versions.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message