Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Date: Sat, 11 Feb 2012 21:18:47 +0100
From: Gilles Sadowski <gilles@harfang.homelinux.org>
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [Math] Make everything "Serializable" ?
Message-ID: <20120211201847.GQ12351@dusk.harfang.homelinux.org>
Mail-Followup-To: Commons Developers List <dev@commons.apache.org>
References: <20120210194034.GM12351@dusk.harfang.homelinux.org>
 <903E7F1AC6BD414A96DBC9D7008AB5E0@BillPC>
 <4F36342C.9070507@free.fr>
 <CAOGo0VZ6y4b966noOab+aBJmQ9vZXgCYmeTcogYELLt7y0uUSQ@mail.gmail.com>
 <4F365F33.30207@free.fr>
 <CAOGo0VZJ=BVaYE5ywvTp8K_E8WQX4xeDsGBircutkY0AVKwVyA@mail.gmail.com>
 <20120211174628.GP12351@dusk.harfang.homelinux.org>
 <4F36B4ED.5010102@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4F36B4ED.5010102@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-DCC-scarlet.be-Metrics: sif 20001; Body=1 Fuz1=1 Fuz2=1
X-Virus-Scanned: clamav-milter 0.97.1-exp at sif
X-Virus-Status: Clean
X-Virus-Checked: Checked by ClamAV on apache.org

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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org