[ENH] Constraint Framework

Stephen Pair spair at advantive.com
Tue Jun 8 21:51:18 UTC 1999


I've put a little constraint framework at http://www.advantive.com/squeak
and attached it as well.  The following is clipped from the tutorial:

-------
Constraint Framework for Squeak
by Stephen Pair

I.  Introduction

  This work represents something that I've desired to try for a long time.  I
hope that this first iteration provides the Squeak community with a useful
QA utility and serves as a launching point for many new enhancements to the
constraint framework.

  The constraint framework provides a mechanism by which a developer in
Squeak can specify constraints for arguments passed into a method.  As such,
a new item (called 'constraints') has been added to the method menu of the
browser and the context menu of the debugger.  At the present, selecting
this item will open a workspace that allows you to edit the constraints of
the method in question.  It is envisioned that a better user interface will
be developed in the future.

  Currently, the only type of constraint that is supported is a
BlockConstraint.  A BlockConstraint specifies a monadic block, into which a
method argument is passed, and out of which a Boolean is expected.  A
typical BlockConstraint might have a validation block that looks something
like:

   [ :arg | arg isKindOf: String ]

This block would check whether or not it's argument is a String.  It is
envisioned that additional types of constraints will be added to the
framework.  For example, one might want a ValueConstraint that checked
whether an argument was included a set of values.  Also, even more
ambitious, one might create an interface (protocol) system that would test
whether or not an argument supported a certain interface.  Of course, all of
these constraints can be expressed using a BlockConstraint, however, for the
purposes of inferring relationships, BlockConstraints would be much less
useful.

  Currently, constraints are only employed for validating method arguments.
In the future, a nice enhancement would be to allow slot variables to be
constrained.  For now, there are two scenarios where constraints are
employed.  The first scenario is in the debugger.  When debugging a context
stack, any contexts where a constraint was violated will be shown in bold
face.  This is useful in correctly problems further up the stack, instead of
correcting symptoms at the top of the stack.  The second scenario where
constraints are employed is in BlockContext>>validateConstraints.  This
method will step through the block of code (much as the Debugger does) and
checks each context to see if it is in violation of a constraint, if it is,
execution halts, allowing one to see and correct the ill mannered code.

  Constraints are cached in a class variable of AbstractConstraint, but
actually stored as generated methods in the class in which the method
appears (instance or class side).  The generated methods are called
#instanceMethodConstraints and #classMethodConstraints.  These methods can
be modified by hand as long as you following the instructions in the
generated method to update the cache.  This is kind of an ugly way to get
method constraints saved with the sources (but it works).  Also, when you
delete a method, any corresponding constraints do not get removed, so you'll
need to remove these by hand.

  To remove the demo classes from the system, evaluate the following:

   AbstractConstraint removeDemoCode.

  My hope is that this framework will help lead to higher quality software in
Squeak.

II. Class Overview

  The following new classes are provided:

   AbstractConstraint   Abstract class for constraints
   BlockConstraint   Constraint that support test blocks
   DemoPerson    A class for demonstration purposes
   DemoAddress    A class for demonstration purposes

  And, the following classes are modified:

   Behavior
   BlockContext
   Browser
   ContextPart
   Debugger
   MethodContext
   StringHolder

III. Tutorial

  A. A simple intro to the debugger modifications

  A mentioned before, the debugger has been modified such that contexts which
violate a methods constraints are shown in bold.  To illustrate, evaluate
the following expression and then enter the debugger:

  DemoPerson new street: 123; yourself

Notice that the context 'DemoPerson>>street: is shown in bold.  That is
because a block constraint exists for that method which validates whether or
not the argument is a kind of String.  To view the constraint, select that
context in the debugger, open the popup menu, and select 'constraints'
(note: follow the instructions in the resulting workspace to modify the
constraints...don't modify them at this point, the other demo depends on the
current constraints).

  B. Checking for constraint violations during execution

  Another bug exist in our demo.  To see the bug, evaluate the following and
open the debugger:

  DemoPerson new prettyString

Notice that no contexts show up in bold.  That does not mean that no
constraints were violated, it just means that no contexts on the stack
violated their constraint.  Another useful feature is evaluation while
validating constraints.  To illustrate, evaluate the following:

  [ DemoPerson new prettyString ] validateConstraints

Notice that as soon as any constraint is violated, execution stops, allowing
you to inspect the stack at the point where a constraint was first violated.

That's it for now...have fun! - Stephen


Content-Type: application/octet-stream;
	name="Constraints.8June538pm.cs"
Content-Disposition: attachment;
	filename="Constraints.8June538pm.cs"

Attachment converted: Anon:Constraints.8June538pm.cs (????/----) (0000AB35)





More information about the Squeak-dev mailing list