Le 11/08/2011 13:29, Sébastien Brisard a écrit :
You can also have a common interface without modification methods, and two
implementations, an immutable one and a mutable one (I think this is how
Scala containers are designed).
Luc
That is I suppose the cleanest approach, but within the solver's loop,
I need the current solution to be modifiable, while I need the
solution returned by getSolution() to be read-only. therefore, if I
have those two implementations, I will need a deep copy somewhere, no?
Or would the solver be creating a new (immutable) vector at each
iteration? Maybe this is not so much of an overhead, after all. How
about memory?
Perhaps a top level immutable class and a derived mutable class would
avoid copying. Internally, the algorithm would know its instance is
mutable, but it would not advertise it outside and the signature would
only return the immutable class.
This is however neither really clean nor foolproof. Users may think the
reference they get is immutable for everyone, so they could store a
reference, but as the algorithm may change it under the hood, it would
break users assumptions.
Concerning memory, I would say that with modern computer, copying a few
megabytes is really not a problem. This does not scale up to gigabytes
or terabytes. In these cases, I guess we can rely only on documentation
and warn users that they get a reference to internal objects and that
they should *never* change them. The only thing we can do to improve
this is adding a read-only wrapper as you suggested (I think) some
messages ago.
There is no perfect solution.
Luc
On the other hand, referring to your previous message: I actually like
the fact that the observer is responsible for making deep copies. By
default, this minimizes the number of deep-copies.
Sebastien
---------------------------------------------------------------------
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
