Stephen,

Now there's an interesting idea! I think this should work pretty nicely
if every class can handle #doesNotUnderstand: appropriately (I believe
that's the only critical message here). You could try an experiment
along the lines of disabling superclass lookup for all but DNU and see
what happens ;-)

Efficiency-wise I would guess that you will be spending quite a number
of bytes on the method dictionaries of the classes since you'd have
everything from Object/Morph in each of the leaf classes. But other than
that I don't see anything problematic.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Stephen Pair
> Sent: Wednesday, December 11, 2002 4:41 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Eliminating superclass lookup in the VM (and dynamic 
> composition of behavior)
> 
> 
> I've been messing with the idea of traits recently (I need them for
> adding transactional behavior to arbitrary classes in the system).  To
> satisfy my immediates needs, I've built a "mini-traits" capability (to
> hold me over until Andrew and Nathanael gets their stuff 
> out).  Anyway,
> I've found myself managing the visibility of trait methods in my
> Smalltalk code.
> 
> While doing this, a thought has occurred to me: does it even 
> make sense
> to have the VM traverse a superclass chain when looking for a method?
> Why not just have the VM just look at the single method dictionary
> directly attached to a behavior and manage the visibility, etc of
> methods in Smalltalk?  Primitive method dictionaries (those 
> designed for
> consumption by the VM) would be nothing more than flattened 
> views of the
> methods that are applicable to a given class.  Methods that access
> instance variables should be the only ones that might need a 
> physically
> different compiled form.  This would also have a side benefit of
> allowing subclasses to have a different instance variable 
> orderings than
> their superclasses...which in turn might facilitate more creative ways
> of composing behavior.
> 
> I mean heck; we even have places in the Smalltalk code where 
> we have to
> flush the VM method cache...these places would be exactly 
> where we would
> want to reconstruct the primitive method dictionaries.
> 
> I've found that I'm managing the visibility of trait methods by
> controlling what happens when adding an removing methods, etc.  It
> occurred to me that if I can do this with relative ease with 
> traits, why
> not do it with normal inheritance?
> 
> Has this been done before?
> 
> - Stephen
> 
>