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 (athena.apache.org: domain of sebastien.brisard@gmail.com
 designates 209.85.220.171 as permitted sender)
MIME-Version: 1.0
Sender: sebastien.brisard@gmail.com
In-Reply-To: <4E44351F.5060000@gmail.com>
References: 
 <CAGRH7HqxUb2y1HmFt9VJ-kxsXwipk_MdO0D=rNuazmGPNOTVrA@mail.gmail.com>
	<1313048561.2738.2.camel@knuffelchen>
	<CAGRH7Hp=3O3fNuyW57hJWJgZNb_pG2TgCd0kXfayT+OeZrKdgA@mail.gmail.com>
	<1313052399.2877.6.camel@knuffelchen>
	<CAGRH7Hqtv3TKbq0Z-LzR3dr7J0qY1aE+cv-u7E0Ts4++UudbKw@mail.gmail.com>
	<4E43A1BB.3050508@free.fr>
	<CAGRH7HpDeA1ZF4ofmudOQWadYfKDCTLc9r=j0n2jGb_Eo=Ec5w@mail.gmail.com>
	<20110811112236.GB2590@dusk.harfang.homelinux.org>
	<4E44351F.5060000@gmail.com>
Date: Fri, 12 Aug 2011 05:41:43 +0200
Message-ID: 
 <CAGRH7HqHPO7fzvP3md4ymS5KVEE8mtkH31-xGfggCGpsJHwxHg@mail.gmail.com>
Subject: Re: [math] Read-only RealVector
From: =?ISO-8859-1?Q?S=E9bastien_Brisard?= <sebastien.brisard@m4x.org>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,
it's clear I think that there is no really fool-proof solution, but
that's OK I think. The idea would be to avoid accidental modifications
which could be catastrophic. But nothing could prevent an evil
programmer to do its evil job. I like what was earlier pointed out:
Javadoc should be very detailed on these issues.
About having a really immutable vector, it's of course a desirable
feature, but thinking about it, it would be nice to be able to combine
both immutable vectors and mutable vectors. Question is: should the
result be mutable or immutable ? Example
immutale.add(mutable), and the converse mutable.add(immutable). Should
the results be mutable? immutable?
Following the approach in UmmodifiableCollections is probably what
I'll do, except if you like the following (VEEEEERY simple) approach
better. Instead of having a method
RealVector getSolution()
how about specifying
RealVector getSolution(boolean deep)
if deep is true, it returns a deep copy, if not it MIGHT (but the
contract of the method does not make it compulsory) return a shallow
copy. The Javadoc should clearly state that if deep is true, then the
user should not modify the returned vector.
Looking forward to hearing what you think,
Sebastien


2011/8/11 Phil Steitz <phil.steitz@gmail.com>:
> On 8/11/11 4:22 AM, Gilles Sadowski wrote:
>> Hello S=E9bastien.
>>
>>>> Well, in fact I would very much like to have immutable vectors too.
>>>> Immutability is really a way to simplify implementations. Surprisingly=
 it
>>>> sometimes also decrease time and memory consumption, because defensive
>>>> copies littering user code can be avoided.
>>>>
>>> Luc, I have a silly question. Why do you think immutable vectors would
>>> prevent defensive copy ? Creating an immutable vector from an existing
>>> mutable vector would require a defensive copy, wouldn't it?
>>> Thats the reason why I'm talking about read-only vectors, and not
>>> immutable vectors.
>>> The solver would keep a reference to the underlying (mutable) vector,
>>> so would be able to modify (indirectly) the read-only vector.
>>> The observer would only have a reference to the read-only vector, so
>>> would not be able to modify the underlying vector.
>> I think that you were right to stress the difference between immutable a=
nd
>> read-only.
>> If I'm not mistaken, in JDK parlance they call the latter "unmodifiable"
>> (cf. the methods "unmodifiableCollection" and siblings in the standard c=
lass
>> "java.util.Collections").
>>
>> The idea which you referred to at the beginning of this thread is exactl=
y
>> what they do: The wrapping class throws "UnsupportedOperationException" =
from
>> any "mutating" method.
>>
>> What Luc said is that when you pass an (already) immutable object, you d=
o not
>> have to make a copy; a reference is as safe.
>>
>> I'm not sure whether that would still be true with an unmodifiable
>> reference. I.e. couldn't it be cast to its underlying modifiable referen=
ce?
>> However that would be on-purpose nasty code, not a mistake on the part o=
f
>> the checker code.
>>
>> So, a utility method like
>> =A0 public static RealVector unmodifiableRealVector(RealVector v)
>> in class "AbstractRealVector", would fit your need, IMO.
>
> +1 - looks to me like what is needed is an unmodifiable view,
> exactly like what the UnmodifiableCollections provide. =A0 What is
> returned in the methods analogous to the above in
> Collections.unModifiableXxx are instances of private static inner
> classes that decorate the actual parameter and delegate, throwing
> UnsupportedOperationExceptions for mutators. =A0See either
> [collections] or the Harmony code [1] for examples.
>
> Phil
>
> [1] http://s.apache.org/XJ4
>>
>>
>> Best,
>> Gilles
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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