On Tue, May 08, 2012 at 08:43:53PM +0200, Thomas Neidhart wrote: > On 05/08/2012 01:44 PM, Gilles Sadowski wrote: > > > 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. > > I do not want to start a heated discussion on this topic again, but I > would like to know what you mean with: it was not implemented properly.
There was a heated discussion here: https://issues.apache.org/jira/browse/MATH-742 > The class in question contains a double and a double array. Making it > serializable with a serialVersionUID is everything you need to do, or am > I missing something important? http://www.xyzws.com/Javafaq/what-are-the-precautions-for-implementing-serializable/53 [And the reference.] > > 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. > > It think your use of words does not reflect what people have in mind > when talking about this issue. "sloppy" implies careless use of > serialization, something I am pretty sure luc does not have in mind > (actually I know considering his other works). "Sloppy" is the right term, not to be dismissive, but to reflect "good enough for what I need in my application", which might not be good enough for a (supposed to be) state-of-the-art library. > otoh, the tags as mentioned by sebb are also not "the" solution to the > problem imho. I fail to find a practical use of them, and know at least > of one open-source project that bans their use by policy. Maybe that you are right; I'm no expert. And I would also tend to make a sloppy usage of serialization whenever I need it! I just think that "serialization" is not a necessity for CM, and that it is too time-consuming to maintain for what it's worth. [As Sébastien said, there are other priorities...] > But, I guess we will never come to a conclusion on this topic, so thats > why I wrote that things should be kept as they are as long as there are > no complaints about their malfunction. In fact there are several issues > that talk about missing serialization support, and none that complains > about broken support. ;-) It depends on what you mean by "support". Back to the policy question. We can choose to provide partial support, but _that_ would in fact be broken support. We know it, now; and who is going to fix it when someone complains? Rather let people select an appropriate tool for the task at hand: CM for for computing the results and something else for serializing them. [My view is that we should preferrably have the CM code stay (or become) cleaner (and thus more maintainable) rather than spare a few additional lines in user's code.] -0 for solving such issues in the sloppy way (just indicate in the Javadoc that is so: No future/backward/cross version compatibility whatsoever). Best regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
