sebb a écrit : > On 22/05/2009, Luc Maisonobe <luc.maison...@free.fr> wrote: >> sebb a écrit : >> >>> On 22/05/2009, Phil Steitz <phil.ste...@gmail.com> wrote: >> >> Luc Maisonobe wrote: >> >> >> >>> Ted Dunning a écrit : >> >>> >> >>> >> >>>> In favor or not, Serializable shouldn't in in widely used interfaces. >> >>>> >> >>>> As an example, a Lucene index is a reasonable implementation of a >> sparse >> >>>> matrix. >> >>>> >> >>>> Would you require that I have to figure out how to make it serializable >> >> just >> >>>> because I declare it as a Matrix? >> >>>> >> >>>> Do you imagine that most developers will do more than just punt in such >> >> a >> >>>> situation if the interface absolutely requires that the object be >> >>>> serializable? >> >>>> >> >>>> Leave it to particular implementations to be serializable or not. >> >> Please, >> >>>> please, please don't force it into the contract for all >> implementations. >> >>>> >> >>>> >> >>> So we have reached a consensus: remove Serializable from interfaces and >> >>> push it down to implementations only. >> >>> >> >>> >> >> +1 >> >> >> >>>>> Any volunteer to do this rather boring work ? >> >>> >> >>> >> > >> >>> I can make a start on it. >> > >> > I suggest that the implementations are flagged (e.g. with TODOs) until >> > the serialization implementation has been checked and documented. >> > >> > WDYT? >> >> It sounds good. Many thanks. >> >> > > Just started to look at this, and the first interface I checked is > MultivariateMatrixFunction. > > This does not have any implementations, except for anonymous classes > in some Test classes.
The interface is intended to be implemented by users of the optimization package. > > In this case, presumably only the interface needs to be updated? Yes. > > Would it be useful to record in the Javadoc is the interface used to > have Serializable? > [As well as in the release notes, of course] In this case, I don't think so. It is a new interface not yet published. > > I think this might be useful, but if no-one else does, then there's no > point doing it. > > --------------------------------------------------------------------- > 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
