Re: [boost] [review][constrained_value] Review of Constrained ValueLibrary begins today

Subject: Re: [boost] [review][constrained_value] Review of Constrained ValueLibrary begins today
From: Robert Kawulak (robert.kawulak_at_[hidden])
Date: 2008-12-01 20:34:28

Hi Stjepan,

You have a very nice gift of catching all possible inaccuracies. :D

> From: Stjepan Rajko
> "It can be used just like the underlying object":
> I have a suspicion that it can't be used "just like" the underlying
> object in all circumstances :-)  I assume you can't call member
> functions of the underlying object if it's a class type (with the same
> syntax), or provide a constrained<int> as an argument to a function
> that takes an int &.

Of course you're right, this is an informal definition and expresses rather a
desire, a design goal, which of course cannot be fully achieved due to the
language limitations.

> Could you provide a slightly more precise
> explanation? 

I'll try. Some hints? ;-)

> *((iter++).value())
> ... so I assume you can't do *(iter++).  (if so, why not?)

No, you can't. This is because (iter++) is of type constrained<...>, and while
it is implicitly convertible to the underlying iterator type, it doesn't have
the * operator (actually, it doesn't have any non-mutating operators
overloaded). It couldn't have the * operator, because in general case it
couldn't know what should be the return type.

> "it can be assigned only a value which conforms to a 
> specified constraint":
> when you say assigned, I'm thinking of the assignment operator, but
> you constrain more than that. Perhaps there is a more inclusive way of
> saying this? (maybe "it can only hold values which conform to a
> specified constraint"?)

Again, you got me here. Maybe "it can only be given values..."? My intention was
to stress the fact, that the constraint checking happens each time the object is
actually modified (and it is usually modified through the assignment operators,
although not exclusively).

> In your example "Object remembering its past extreme values", the
> policy is changing the constraint object directly.  But, in your
> tutorial, you have:
> "Constraint of a constrained object cannot be accessed directly for
> modification, because the underlying value could become invalid
> according to the modified constraint. Therefore the constraint of a
> constrained  object is immutable and change_constraint() function has
> to be used in order to modify the constraint. ..."
> Is the example violating how the library should be used?

No. From the perspective of a constrained object's user it's true that the
constraint cannot be accessed directly for modification in any way. OTOH the
error policy is allowed to modify anything within the constrained object when
invoked (as long as the value remains constraint-conforming). This is what the
policy in the example does.

> The value() function returns the underlying object by const &... so,
> I'm assuming that the constraint is not allowed to depend on any
> mutable parts of the underlying object's state?

The constraint may depend on any state, mutable or not -- it's the constrained
object's task to make sure that the value is immutable for the "outside world"
(and it does so by providing only value access methods returning a const
reference).

Thanks for feedback,
Robert