How about this:

Have a single method that all classes have, which is the "message
handler" method.  Such a method might look like:

: aMessage

	<primitive: normalMethodInvocation>
	"Failure code goes here"

The special syntax here would be that there is no keyword to this method
(just ":").  The default implementation in ProtoObject would have the
normal code for #doesNotUnderstand: inserted in place of "Failure code
goes here"...or it could simply make a call to #doesNotUnderstand:.  The
parameter could also be any kind of object (not just an instance of
Message).

Behaviors that need to specialize message lookup could override this
method.  This should be easy for the VM to optimize for the normal cases
(a bit flag could indicate to the VM which classes use this primitive).

- Stephen

> -----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 1:30 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: Eliminating superclass lookup in the VM (and 
> dynamic composition of behavior)
> 
> 
> I guess what I'm really after is the ability to have more 
> control over the manner in which behavior is composed.  So 
> far, the best platform for doing that seems to be Self.  
> However, even in Self, I think the message binding algorithm 
> is fixed.  It would be nice to be able to override the 
> default message binding algorithm that the VM employs.
> 
> - Stephen
> 
> > -----Original Message-----
> > From: squeak-dev-admin at lists.squeakfoundation.org
> > [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> > Behalf Of tblanchard at mac.com
> > Sent: Wednesday, December 11, 2002 1:14 PM
> > To: squeak-dev at lists.squeakfoundation.org
> > Subject: Re: Eliminating superclass lookup in the VM (and 
> > dynamic composition of behavior)
> > 
> > 
> > I found myself sitting next to Ira Forman at an OOPSLA workshop in
> > 1995.  At the time he was one of the main designers of IBM's SOM 
> > library.  It was something like his  3rd year presenting SOM. 
> >  We were 
> > talking about how he handles multiple inheritance and he said his 
> > solution was to basically copy the dispatch table (method 
> dict if you 
> > like) into each class.
> > 
> > Partly because SOM allowed you to attach before, after, and around
> > methods to arbitrary locations in the class hierarchy and the 
> > bookkeeping got too hairy if the point of dispatch was 
> > somewhere other 
> > than the attachment class.
> > 
> > So I have heard of it being done.  Sounds like the classic
> > size v speed 
> > tradeoff.  I'm a bit worried that the size of the image 
> will explode.
> > 
> > On Wednesday, December 11, 2002, at 04:40  PM, Stephen Pair 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
> > >
> > >
> > 
> > 
> > 
> 
> 
>