Le 11/08/2011 12:24, Sébastien Brisard a écrit :
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?
Yes, of course. What I meant is that when users don't have the choice
and are forced to use only mutable objects, then in many places they do
defensive copying, just because they do not even know if some other code
will attempt to modify the object in place after they have retrieved it.
So you end up with "B b = a.getB().clone()" to protect the B instance.
When instances are known to be immutable, you don't copy them (and you
often neither implement Cloneable nor set up copy constructors).
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.
The problem with this approach is that the observer could not preserve
the instance across several calls (for example to compare the instance
from one previous call to the current one). If a specific observer wants
to do that, then it needs to be able to copy the instance. If the
observer knows the object is immutable, it will only preserve the reference.
Luc
Sébastien
---------------------------------------------------------------------
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
