Eliminating superclass lookup in the VM (and dynamic composition of behavior)

Anthony Hannan tony at housechk.com
Wed Dec 11 15:47:01 UTC 2002


Hi Stephen,

This is basically the discussion we had before about traits being the
same as multiple inheritance (except for the use of the 'super' pseudo
variable).  Inheritance can be implement either by looking throught the
chain at runtime or flattening all the methods to concrete classes at
compile time.  The trade off is time vs. space.  But with the method
cache you have a mix of both which is probably the best solution.  You
only "flatten" method that are called in the method cache.

Cheers,
Anthony

"Stephen Pair" <spair at acm.org> wrote:
> 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



More information about the Squeak-dev mailing list