OK, I sort of like the idea behind the mechanism - but I think its a 
distinct mechanism from "inheritance" - as pointed out there are the 
issues of how super is bound.

I'm still not comfortable with extensions of Object becoming 
superclasses of Object.  I think that could introduce some ugly 
circularities.  Also, since these behaviors are chunks of behavior sans 
state - something else has to define the structure of the storage - so 
we have two kinds of things now - classes with state and stateless 
classes.

If they are two things I think they deserve two unconfusing names.

So I don't object to the mechanism per se - but I don't much like the 
terminology.  I think it is going to be confusing - especially to users 
of more conventional pretend OO languages (the [CJ]++# crowd).

Anyhow, whether its called traits, categories, bundles, or snozwangers, 
I'm looking forward to getting the mechanism.

On Wednesday, November 20, 2002, at 02:00  AM, Anthony Hannan wrote:

> 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
>