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

Subject: Re: [boost] [review][constrained_value] Review of ConstrainedValueLibrary begins today
From: Stjepan Rajko (stjepan.rajko_at_[hidden])
Date: 2008-12-07 13:15:18

On Sun, Dec 7, 2008 at 10:49 AM, Robert Kawulak
<robert.kawulak_at_[hidden]> wrote:
>> From: Stjepan Rajko
>
>> I tried to suggest a way in which the library can deal with this here:
>> http://tinyurl.com/6hlb8o
>>
>> Do you find problems with that strategy?
>
> I've seen your post. Sorry for no reply yet, but I need some time to think about
> the idea to understand it well enough. ;-)
>

Yeah, in retrospect I realized that I wasn't describing my assumptions
/ starting points very well.  My reply to Gordon's post offers some
additional thoughts but I think also falls short of being very clear.

I think the fundamental shift is the separation between the invariant
(which is what you would like the library to guarantee) and a test
(which is a test related to the invariant).  The current design /
documentation roll both of these into a single entity - the
constraint.  What I am proposing requires that these two be separated,
and that the only requirement be that a passing test guarantees the
invariant (but a failing test need not imply that the invariant is not
satisfied).  The test is what is implemented (just like the current
constraint), but the invariant is only documented/guaranteed.

Hence, a test that always fails would be a legal test no matter what
the invariant is (just like a policy that always throws is a valid
policy no matter what the invariant is).  Of course, the library is
the most useful when the test checks for the invariant exactly, but in
cases like floating point comparison, the invariant is somewhat of a
moving target and a perfect test is difficult.  Allowing imperfect
tests (that still guarantee the invariant) provides a way to deal with
such cases.  At the same time, your library is still maintaining the
same guarantee, because the test is providing it for you.  This is
just like the policy providing the same guarantee in cases where the
test fails (but separating the invariant from the test will require
you to make a choice here - should the policy guarantee the invariant
only, or should it also guarantee a passing test?)

Like I said, the most useful scenario is when test <==> invariant.
This is what you currently have and I think that should remain the
focus of the library.  As far as what could to be done, I am only
suggesting you document and discuss what happens in the case where
only test ==> invariant holds.

As my own understanding of this idea has evolved quite a bit in the
past couple of days, my posts on the subject are probably not very
consistent - but hopefully the above description makes them a bit more
digestible and you can extrapolate something that you think might work
for the library (or find a reason why the library shouldn't support
it).

Best,

Stjepan