2012/1/4 Luc Maisonobe <luc.maison...@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-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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
