On Thu, Feb 23, 2012 at 11:32:54AM +0000, sebb wrote:
> On 23 February 2012 11:19, Gilles Sadowski <gil...@harfang.homelinux.org> 
> wrote:
> > On Thu, Feb 23, 2012 at 10:55:51AM +0000, sebb wrote:
> >> On 16 February 2012 16:17,  <l...@apache.org> wrote:
> >> > Author: luc
> >> > Date: Thu Feb 16 16:17:14 2012
> >> > New Revision: 1245061
> >> >
> >> > URL: http://svn.apache.org/viewvc?rev=1245061&view=rev
> >> > Log:
> >> > Removed unneeded clone.
> >> >
> >> > The clone did not protect the array used, only the reference ones.
> >> > JIRA: MATH-650
> >>
> >> -1
> >>
> >> That was the whole point of the clone - to protect the original external 
> >> data.
> >
> > Please (re-)explain what you mean by "protect".  Cf. my comment on the
> > JIRA page.
> 
> See also your comment of 30/Nov/11 00:31.

I know, but my latest comment overrides that one.

> The arrays in FastMathLiteralArrays are private, but the access
> methods are not, and returning an array allows the caller to modify
> array elements.

It's true, but unless I'm mistaken, it doesn't matter since in the end there
is one and only one array that will be _used_ (the modified one) and having
a pristine copy somewhere else will not prevent the dire consequences of
using the modified one... ;-/

> If you don't want the memory overhead of a clone, then one could use
> array entry getters instead.

It's not that: It is because "clone" gives a false sense of security.

Yes, getters would be _really_ secure, as they would prevent an inadvertant
CM developer to commit a bug in the "FastMath" class. But a _user_ of
"FastMath" can anyways never access the arrays (as the references/copies are
"private" to "FastMath"), so I was wondering whether the additional layer of
security was really worth it (in case a performance loss would accompany the
getters; if not, then fine, fine).


Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to