Re: [boost] [review][constrained_value] Review of ConstrainedValueLibrary begins today

Subject: Re: [boost] [review][constrained_value] Review of ConstrainedValueLibrary begins today
From: Robert Kawulak (robert.kawulak_at_[hidden])
Date: 2008-12-09 20:20:43

> From: vicente.botet
(I have slightly changed the order of citations.)

> I don't understand why an 
> error policy can modify the value or the constraint.

Constrained object treats each error as possibly recoverable and performing the
recovery is the task of the error policy. Therefore the error policy is
responsible for leaving the constrained object in a valid state. To allow for
this, an error policy must be able to adjust at least the value.

And I see no reason to disallow changing the constraint too. If something:
* is not potentially dangerous,
* costs nothing,
* does not add extra complexity for the normal usage,
* creates opportunity to use the library in some new, creative way, if somebody
wishes to,
then why should it be banned?

> The wrapping and cliping classes are not exactly constrained 
> values, they are adapting a value of a type to a constrained 
> value. So I would prefer to have a different class for them 
> taking a constraint adaptor that would take the value by 
> reference and adapt it to the constraint.

So, having the adaptor, why its underlying value should be a constrained object
at all? If the adaptor adjusts the value so it always meets the condition, then
the error policy of the constrained object would not be used anyway.

> I find that the extreme example "bounded object with memory" 
> is not a good example of constrained_value because not 
> constrained at all.

This is why I called it "extreme" example. :P

> "bounded object with memory" could be better 
> considerd as a monitored value.

I agree.

Best regards,
Robert