Hi Todd,

tblanchard at mac.com wrote:
> > Yes, you would add the behavior required by the package in a new
> > behavior and make Object a subclass of it.
> 
> Why is it a subclass?  These "classes" you are describing don't seem 
> have much in common with the classes we have now.  For one thing, 
> you've mentioned that there is no state.  But Smalltalk classes 
> generally do have state.  So are you implying we change classes in 
> Squeak to not have state, or are you saying these mixins you are 
> proposing aren't really classes like we have now but something else?
> Personally I'd rather have method bundles (categories) that add to a 
> class without requiring mucking about with the class hierarchy.

You may have already figured out by now from my other emails, that I'm
proposing a single type of behavior object, call it behavior, class,
trait or whatever.  A behavior holds a set of methods and inherits from
other behaviors.  "Inherit" means include methods from other behaviors,
and can be implemented in the following ways:
	(1) search inherited behaviors during method lookup (our current
implementation), or
	(2) copy inherited methods into the inheriting method dictionary
(traits composition), or
	(3) add new method bundles (class extensions), like you suggest.
All of these are forms of inheritance.  1 and 2 are equivalent except
the former consumes more time and the latter consumes more space
(ignoring method cache).  3 is equivalent to inherting the class
extension and giving it precendence over previously added extensions and
other inherited behaviors (a la CLOS).  This ordering is problematic as
raised in the Traits paper (page 5) and its references.  This is also
why I claim packages should not use this technique.
	So I'm saying inheritance is fudamentally the same so lets implement it
the same throughout the system.  I'm further saying all behaviors are
the same (after you remove instance variables) so lets implement them
the same as well.
	I'm proposing that we replace instance variables with accessor methods,
so all behaviors are just collections of methods and equally reusable. 
It's like shifting the state responsibility from the behavior to the
method, which I think is appropriate since even local senders don't care
how a selector is implemented (stored value or method).
	These accessor methods need to check the class of the receiver before
reading/writing.  This is only necessary because we optimize slot access
by translating accessors into indices.  If objects were dictionaries
keyed by accessor than this would not be necessary and the accessors
would work on sub-instances also.  Subclasses could then override an
accessor if it wants, but with indexed slots they have to (its no big
deal).  So when instantiating a behavior the instance has the same
number of slots as the number of write accessors in the behavior.  Each
accessor has an assigned slot number.

> As for adding protocol to Object - its done fairly often - simple 
> example is to have a project Foo that manages FooElements - I'm quite 
> likely to add a method category FooExtensions to Object and put an 
> isFooElement method (returning false) that I override in FooElement to 
> return true.

FooExtenstions would be a super behavior of Object, which is equivalent
to adding its methods directly to Object (see #3 above).

Cheers,
Anthony