>      Although I must classify myself as a Squeak newbie, I do feel that 
>      that this would be the correct approach since Behavior appears to be 
>      just a specialized kind of node.

Actually, nearly all objects are specialized kinds of nodes...
	either they have references to other objects, or they do not,
	either other objects reference them, or not.

Although the parent/child pattern is common, I normally do not feel
it is a sufficiently important part of the object in question to warrant
making that object a subclass of some "TreeNode" class.

If there were a reasonable mixin facility, then it would be worthwhile
to have a single implementation that gets used over and over.  But I would
want it to be better than that, as I would want the mixin to be parameterized
so that I could change the names of the methods and instance variables to
be more reflective of their use within the context of the new class being
constructed.

As it happens, these days I do use this pattern over and over, and I
rubber stamp that part of the object from a template that I borrow from
another class having similar character.  But I do not want to end up
with methods being the same across totally different classes.

So one thing I've considered doing is to change inheritance a bit, so that
it does not run up through classes, but up through the patterns out of which
classes are constructed.  I've been wanting to do this for some time, but
unfortunately I've also been wanting to hook Squeak up to an OO database
such as Texas, rebuild the entire GUI framework, install a MOP, etc. etc.

So basically I'm an idea guy, I guess...

( this is a longish way of saying that Object IS a generic node class ).

les