Re: [boost] [review][constrained_value] Review ofConstrainedValueLibrary begins today

Subject: Re: [boost] [review][constrained_value] Review ofConstrainedValueLibrary begins today
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-12-10 13:37:52

----- Original Message ----- 
From: "Robert Kawulak" <robert.kawulak_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, December 10, 2008 2:20 AM
Subject: Re: [boost] [review][constrained_value] Review ofConstrainedValueLibrary begins today

> 
>> 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.

Well, at least you should name it RecoverableErrorPolicy.
 
> 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?

Well the error_policy function follows this prototype
    template <typename V, typename C>
    void operator () (const V &, const V &, const C &) const;
while this one could be enough
    template <typename V>
    void operator () (const V &) const;

I'm realy get convainced that the base type od the constrained class should be monitored and the prototype for a Monitor function should be 
    template <typename V>
    void operator () (V &) const;
 
In this way, the constrained class could be an specialization.

We see that the classes clipping and wrapping can be implemented in a more efficient way by defining a Monitor than defining a Constraint and an ErrorPolicy. So don't need to have a ErrorPolicy prototype 
    template <typename V, typename C>
    void operator () (const V &, const V &, const C &) const;
but 
    template <typename V>
    void operator () (const V &) const;

You extreme example would be a monitored specialization.

>> 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? 

I have no said that. The underlying type could be any value type.

> 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.

Exactly. A constrained_adapteed should not have error policy. The constraintAdaptor must feet the value to the constraint. Replace constrained_adapteed  by monitored if you want.

Best,
Vicente