Boost logo

Boost :

From: Dan W. (danw_at_[hidden])
Date: 2004-01-08 00:37:19

Tanton Gibbs wrote:

> I wrote a framework and a paper on Temporal Invariants. These invariants
> exist or are freed over time. You might get some interesting ideas from the
> paper; a link is attached.

Very interesting. I've many times written invariants only to remove them
later on finding that they didn't always apply.

I'm only half way through the paper, so perhaps my questions are
premature. It would seem to me that two of the keywords depend on the
other two, namely,

always == ! never

And having 'already' seems to make 'eventually' unnecessary. I have only
a boolean (char actually) in my invariants class, and I'm planning to
get rid of it, as having state in the invariants class is an invitation
for for using invariant checks on invariant base itself. So I wish not
to have to store whether 'eventually' has indeed ever come true. And
this may not be justified anyhow:

Suppose I have a class which at some point allocates a container. Until
such container is allocated, some of the public functions may not apply.
Now, all I need to debug un-timely calls to such functions are
preconditions in those functions to the effect that the container exists
'already'. Admittedly, my use of the term "precondition" is misleading,
since preconditions are the business of clients and must be expressed in
terms of conditions visible to the client, as opposed to private vars.

I'm not sure I can 'prove' this, but my intuition is telling me that if
a class requires its invariants overseeing mechanism to have state of
its own, perhaps the class is not well designed to begin with.

I am considering adding an ALREADY mechanism, as I read your paper;
thank you.


Boost list run by bdawes at, gregod at, cpdaniel at, john at