----- Original Message ----- From: "Robert Kawulak" <robert.kawulak@gmail.com> To: <boost@lists.boost.org> 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