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. 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? > 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). 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. 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. ;-) Good evening Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
