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. Phil > Sebastien > > > 2011/8/11 Phil Steitz <phil.ste...@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-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
