I don't know that you want to get into supporting long-term
serialization support.  I would say CM should support transient
serialization (if that makes any sense), such as
marshalling/unmarshalling.  If you guarantee long-term serialization
support (reading data from serialized for much later, perhaps by
another version of CM), then we get into the nasty serialization test
cases like Commons Collections has/had.  Yuck!

On Tue, May 8, 2012 at 2:43 PM, Thomas Neidhart
<thomas.neidh...@gmail.com> 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.
>
> 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
>

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

Reply via email to