On Sun, Dec 7, 2008 at 10:49 AM, Robert Kawulak <robert.kawulak@gmail.com> 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