You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Sébastien Brisard <se...@m4x.org> on 2012/01/04 02:21:25 UTC
[math] Serializable transforms (MATH-677)?
Hi,
I'm currently working on MATH-677 (cleaning-up o.a.c.m.transforms). I
notice that all classes in this package implement Serializable. I'm
wondering whether there is a practical use for this. If not, I would
rather remove this functionality. What do you think?
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Serializable transforms (MATH-677)?
Posted by Sébastien Brisard <se...@m4x.org>.
2012/1/4 Luc Maisonobe <Lu...@free.fr>:
> Le 04/01/2012 10:06, Sébastien Brisard a écrit :
>> 2012/1/4 Luc Maisonobe <Lu...@free.fr>:
>>> Le 04/01/2012 02:21, Sébastien Brisard a écrit :
>>>> Hi,
>>>> I'm currently working on MATH-677 (cleaning-up o.a.c.m.transforms). I
>>>> notice that all classes in this package implement Serializable. I'm
>>>> wondering whether there is a practical use for this. If not, I would
>>>> rather remove this functionality. What do you think?
>>>
>>> I like to have everything serializable (but probably belong to a
>>> minority here). My rationale is that when a user put one of our class as
>>> a field in its own classes and need his classes to be serializable, he
>>> needs to have our classes serializable. This also is almost never a
>>> problem to add this, as it is often simply a matter of declaring an
>>> interface and putting a static serializable ID field.
>>>
>>> I use it a lot for ODE step handlers for example, as it allows to store
>>> the complete history thoughout an integration run and reuse it later. As
>>> there are pointers back and forth between various parts (step handlers,
>>> events handlers, integrator ...) many classes in this package must be
>>> serializable. I guess similar rationale may apply to other packages.
>>>
>>> Luc
>>>
>> Actually, I didn't realize that the use-case you are talking about
>> could apply to my simulations as well... which make heavy use of FFTs.
>> So maybe it's better to keep this functionality. Only, I need to be
>> very rigorous with serial version uids ;). Or is it at release time
>> that we care about regenerating these numbers? Is this task somehow
>> automated?
>
> No, the task is not fully automated. I used to rely on eclipse
> generation for this (i.e. I suppressed the field, and when eclipse fired
> a warning I selected an automatic generation in its warning quick fix
> context menu.
>
> However, since then there has been a discussion on the list and it was
> suggested to simply use the date of last file edition for that, in a
> format like 20120104 for todays date for example. This has the
> additional advantage that it provides a hint to know when the class had
> a large change involving fields modifications for example.
>
I was thinking of a tool (mvn plugin?) which would automatically
detect that the UID of a specific class needs to be updated (based on
the analysis of the changes operated on the class). I'm probably
dreaming, though... I'll try and remember to do it each time I commit
a change which requires updates.
Sébastien
> Luc
>
>>
>> Sébastien
>>
>>>>
>>>> Sébastien
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Serializable transforms (MATH-677)?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 04/01/2012 10:06, Sébastien Brisard a écrit :
> 2012/1/4 Luc Maisonobe <Lu...@free.fr>:
>> Le 04/01/2012 02:21, Sébastien Brisard a écrit :
>>> Hi,
>>> I'm currently working on MATH-677 (cleaning-up o.a.c.m.transforms). I
>>> notice that all classes in this package implement Serializable. I'm
>>> wondering whether there is a practical use for this. If not, I would
>>> rather remove this functionality. What do you think?
>>
>> I like to have everything serializable (but probably belong to a
>> minority here). My rationale is that when a user put one of our class as
>> a field in its own classes and need his classes to be serializable, he
>> needs to have our classes serializable. This also is almost never a
>> problem to add this, as it is often simply a matter of declaring an
>> interface and putting a static serializable ID field.
>>
>> I use it a lot for ODE step handlers for example, as it allows to store
>> the complete history thoughout an integration run and reuse it later. As
>> there are pointers back and forth between various parts (step handlers,
>> events handlers, integrator ...) many classes in this package must be
>> serializable. I guess similar rationale may apply to other packages.
>>
>> Luc
>>
> Actually, I didn't realize that the use-case you are talking about
> could apply to my simulations as well... which make heavy use of FFTs.
> So maybe it's better to keep this functionality. Only, I need to be
> very rigorous with serial version uids ;). Or is it at release time
> that we care about regenerating these numbers? Is this task somehow
> automated?
No, the task is not fully automated. I used to rely on eclipse
generation for this (i.e. I suppressed the field, and when eclipse fired
a warning I selected an automatic generation in its warning quick fix
context menu.
However, since then there has been a discussion on the list and it was
suggested to simply use the date of last file edition for that, in a
format like 20120104 for todays date for example. This has the
additional advantage that it provides a hint to know when the class had
a large change involving fields modifications for example.
Luc
>
> Sébastien
>
>>>
>>> Sébastien
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Serializable transforms (MATH-677)?
Posted by Sébastien Brisard <se...@m4x.org>.
2012/1/4 Luc Maisonobe <Lu...@free.fr>:
> Le 04/01/2012 02:21, Sébastien Brisard a écrit :
>> Hi,
>> I'm currently working on MATH-677 (cleaning-up o.a.c.m.transforms). I
>> notice that all classes in this package implement Serializable. I'm
>> wondering whether there is a practical use for this. If not, I would
>> rather remove this functionality. What do you think?
>
> I like to have everything serializable (but probably belong to a
> minority here). My rationale is that when a user put one of our class as
> a field in its own classes and need his classes to be serializable, he
> needs to have our classes serializable. This also is almost never a
> problem to add this, as it is often simply a matter of declaring an
> interface and putting a static serializable ID field.
>
> I use it a lot for ODE step handlers for example, as it allows to store
> the complete history thoughout an integration run and reuse it later. As
> there are pointers back and forth between various parts (step handlers,
> events handlers, integrator ...) many classes in this package must be
> serializable. I guess similar rationale may apply to other packages.
>
> Luc
>
Actually, I didn't realize that the use-case you are talking about
could apply to my simulations as well... which make heavy use of FFTs.
So maybe it's better to keep this functionality. Only, I need to be
very rigorous with serial version uids ;). Or is it at release time
that we care about regenerating these numbers? Is this task somehow
automated?
Sébastien
>>
>> Sébastien
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Serializable transforms (MATH-677)?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 04/01/2012 02:21, Sébastien Brisard a écrit :
> Hi,
> I'm currently working on MATH-677 (cleaning-up o.a.c.m.transforms). I
> notice that all classes in this package implement Serializable. I'm
> wondering whether there is a practical use for this. If not, I would
> rather remove this functionality. What do you think?
I like to have everything serializable (but probably belong to a
minority here). My rationale is that when a user put one of our class as
a field in its own classes and need his classes to be serializable, he
needs to have our classes serializable. This also is almost never a
problem to add this, as it is often simply a matter of declaring an
interface and putting a static serializable ID field.
I use it a lot for ODE step handlers for example, as it allows to store
the complete history thoughout an integration run and reuse it later. As
there are pointers back and forth between various parts (step handlers,
events handlers, integrator ...) many classes in this package must be
serializable. I guess similar rationale may apply to other packages.
Luc
>
> Sébastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Serializable transforms (MATH-677)?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Wed, Jan 04, 2012 at 02:21:25AM +0100, Sébastien Brisard wrote:
> Hi,
> I'm currently working on MATH-677 (cleaning-up o.a.c.m.transforms). I
> notice that all classes in this package implement Serializable. I'm
> wondering whether there is a practical use for this. If not, I would
> rather remove this functionality. What do you think?
+1
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org