commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [math] Read-only RealVector
Date Thu, 11 Aug 2011 10:53:37 GMT
2011/8/11 Sébastien Brisard <sebastien.brisard@m4x.org>:
> OK, this I also think would be useful. But my initial question
> remains, if the object I want to protect is not a RealVector, what do
> you think of my solution ?
> Sébastien

If you create the read-only version by subclassing the writable
version, then you have to ensure that all mutating methods are
overridden.
If a base class is later extended to add a new mutator, the protection is lost.

This can be avoided by using composition, only forwarding safe
methods. However that means the new class is not an instance of the
old class.

Neither is perfect ...

> PS : the problem is likely to occur when listening to other Iterative
> Processes (not only linear solvers). For example, in o.a.c.m.genetics,
> has a StoppingCondition.isSatisfied(Population),
> and Population.addChromosome() would enable the StoppingCondition to
> actually modify the ongoing simulation. Whether it is harmfull, I do
> not know, though.
> So of course, we could come up with a ImmutablePopulation as well, but
> maybe it starts to get complicated?
>
> Sébastien
>
> 2011/8/11 Luc Maisonobe <Luc.Maisonobe@free.fr>:
>> Le 11/08/2011 10:55, Sébastien Brisard a écrit :
>>>
>>> 2011/8/11 Arne Ploese<aploese@gmx.de>:
>>>>
>>>> So you not only want to observe the result, but you want a read only
>>>> RealVector.
>>>>
>>> That's right. I'm sorry, my first message was not clear, especially if
>>> you did not follow the thread on iterative solvers.
>>> I want to observe the *solver*, and the current state of the solver is
>>> a *RealVector*, which should by no means be modified by the observer.
>>> The safest way to do that would be for the solver to have a method
>>> like
>>> public RealVector getCurrentSolution(){
>>>     return x.copy();
>>> }
>>> but that takes both time and memory. So I was thinking of something more
>>> like
>>> public RealVector getCurrentSolution(){
>>>     return new ReadOnlyRealVector(x);
>>> }
>>> which takes virtually no additional memory (and presumably very little
>>> time). The two advantages of this approach are
>>> * it does not jeopardize the whole hierarchy tree, since you do not
>>> have to create a new interface,
>>> * it is quite general, and could be adopted for any base object (not
>>> only RealVector).
>>> The downside is that some methods throw exceptions, which might be
>>> deemed dirty. I don't really know.
>>
>> 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.
>>
>> Jeopardizing the hierarchy tree is not a problem IMHO.
>>
>> Luc
>>
>>> S
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message