On Sat, Feb 11, 2012 at 07:35:25PM +0100, Thomas Neidhart wrote: > On 02/11/2012 06:46 PM, Gilles Sadowski wrote: > > >[I still have to understand why objects that represent mathematical > >algorithms must be serializable. It is quite possible that I miss somehing > >but a use-case would help. In principle, I'd think that we must provide > >accessors that would enable user code to re-construct any CM object; then > >it's up to the user code to create any "Serializable" object for storing > >those data they want to send over the wire, and reconstruct the CM object > >on the other end...] > > I think you have a good point in general, but the case where this > discussion started is not as clear-cut as this. In fact, many > algorithms in CM are a mixture of data structures and algorithms > bound together using OO paradigms, which may not be always the best > solution.
When I mentioned data vs algorithms, I did not mean the "data" (instance variables) that is part of the algorithm which in an OO approach, you bundle together with the methods that operate on them. I think that it is possible to distinguish objects which primarily represent a (user-level) "data" structure from objects that represent algorithms (e.g. something which is aimed a producing a result later on). An example of the former would be an "Array2DRowRealMatrix" (from package "linear"), an example of the latter would be a "Gaussian" (from package "analysis.function"). While it is reasonable (IMO) to expect to serialize a matrix (a "data" structure), it is not so for a "function"; the fact that it can contain instance variables is due to an OO-programming feature, not to the concept itself. > So my conclusion would be to work on improving the code to be more > functional and separate algorithms / data. In the mean time we can > support the users by making their lives easier and support > serialization by default where possible. If somebody has to work on > a use-case that requires more sophisticated methods, well, he/she > will have to find a solution anyway. I would not draw that conclusion. As a Java library, it would not be wise for CM to move away from the OO paradigm. People who choose or use Java are accustomed to this programming style (or, even, like it ;-). Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
