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

Stephen Pair spair at acm.org
Wed Dec 11 15:40:45 UTC 2002


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