Re: [boost] [review][constrained_value] ReviewofConstrainedValueLibrary begins today

Subject: Re: [boost] [review][constrained_value] ReviewofConstrainedValueLibrary begins today
From: Robert Kawulak (robert.kawulak_at_[hidden])
Date: 2008-12-10 22:00:51

> From: vicente.botet

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

The question that I answered here was why error policy can modify the
constraint, while now you're jumping to why error policy takes the constraint as
argument. This has already been answered in my earlier post.

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

Did you do any research of possible use cases? If I were to design a monitored
value class, I'd consider passing both the old and the new value to allow for a
more general usage. For example, the monitor function would be able to log
somewhere how much the value has changed or prevent invalid state transition in
a model of a finite state machine.

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

Maybe. But given optimisation capabilities of compilers, I would say: not much
more. I have been compiling code snippets using wrapping<int> (with dynamic
bounds) to assembly code and the result was as if the code had been written by
hand in an optimal way.

> >> The wrapping and cliping classes are not exactly constrained 
> >> values

It depends how you define constrained value. The design of this library assumes
that constrained object is an object with value conforming to a specified
constraint (so constrained object guarantees that its value belongs to the
specified subset of values of the underlying type). Can you show that this
definition is inappropriate or that wrapping/clipping objects don't fit to it?

The fact that a value is constrained is a contract, and throwing or adjusting
the value are examples of methods (policies) guaranteeing this contract.

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

I thought this is what you meant by saying: "they are adapting a value of a type
to a constrained value".

Best regards,
Robert