The smalltak/V engine, I believe starting in the 3.0 version, did not
have objects point to their classes...instead objects pointed to an
array of message dictionaries, hence all inheritance issues (single and
multiple) were flattened, hence traversal of superclass chains was not
done during message lookup.  There was massive sharing of the method
dictionaries themselves so there was no space explosion.  Additionally
it allowed one to naturally implemented instance-specific
behaviors--just add a new dictionary to the head of the array to hold
methods that are specific to the instance.  The notion of a class was
not really visible at the vm-level, rather, it was a tool/ide
construct...you asked the array of method dictionaries who was
responsible for building it, and that was the class.  Hence all of the
hard issues, like what is the language/environment rules and constraints
on inheritance and instance specific behaviors were not vm issues, but
rather ide/tool/language issues.

-----Original Message-----
From: Stephen Pair [mailto:spair at acm.org] 
Sent: Wednesday, December 11, 2002 7:41 AM
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