It has been brought to my attention that what I meant to say was "assertion
framework."  ;-)

Actually, what this code really does is provide an easy way to "constrain"
the arguments of methods to objects belonging to a domain specified by the
"constraint."  It does this without intruding on the source code of the
methods.  Also, the debugger highlights contexts where such "constraints"
have been violated.

I called it a constraint framework because I envision the constraints
applying not just to method arguments, but also slot variable relationships.
Also, systems of objects could have constraints imposed upon them, with an
easy to use interface for describing and validating these constraints.  I
also had the whole issue of static typing and Java interfaces in the back of
my mind, with an idea to formalize protocols (I believe Dolphin has done
this already) and build new types of constraints based on these formalized
protocols.  My motivation is one of providing tools that enable one to get
the benifits of statically typed languages without the limitations.

As such, the framework is not a constraint solver, as one might have been
lead to believe by the subject.  But, to say it's an assertion framework
would be too limited a view.  I have certainly started thinking how this
approach and constraint oriented systems might intersect (I'm not well
versed in constraint oriented systems).

- Stephen