commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] Read-only RealVector
Date Fri, 12 Aug 2011 05:04:53 GMT
On 8/11/11 8:41 PM, S├ębastien Brisard wrote:
> 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,

I see Gilles' suggestion to add
public static RealVector unmodifiableRealVector(RealVector v) to
AbstractRealVector as a valuable addition, independent of this use
case, and similarly for matrices, implemented using the decorator
pattern the way that Harmony, [collections] and I assume the JDK
does it. So I would vote for that approach and to in general have
getSolution() methods return either copies or unmodifiable views of
results. In this case, I would keep it simple and just have
getSolution return an unmodifiable view (documented in javadoc, of
course).  Note that AbstractRealVector has a copy method and as long
as (the private inner class) UnmodifiableRealVector delegates that
method through, users will be able to create modifiable copies
themselves if they need to.

> Sebastien
> 2011/8/11 Phil Steitz <>:
>> 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
>>>>> 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]
>>> Best,
>>> Gilles
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message