commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Brisard <sebastien.bris...@m4x.org>
Subject Re: [math] Read-only RealVector
Date Fri, 12 Aug 2011 03:41:43 GMT
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ébastien.
>>
>>>> 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 and
>> read-only.
>> If I'm not mistaken, in JDK parlance they call the latter "unmodifiable"
>> (cf. the methods "unmodifiableCollection" and siblings in the standard class
>> "java.util.Collections").
>>
>> The idea which you referred to at the beginning of this thread is exactly
>> 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 do 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 reference?
>> However that would be on-purpose nasty code, not a mistake on the part of
>> the checker code.
>>
>> So, a utility method like
>>   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.   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.  See 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


Mime
View raw message