Stephen

> 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).

There are Smalltalk dialects (e.g., Smalltalk/X) that use just about
this technique: They have a special bit-flag to indicate whether a class
uses the regular VM lookup or just another lookup strategy. Using this
technique, the designer of Smalltalk/X was able to do cool things like
implementing Java inside Smalltalk, etc.

But again, I think it that the hard thing is not to make this work at an
implementation level. This is finally "just" VM hacking. (Don't take me
the wrong way! I don't want to say that writing a good VM is simple at
all. What I mean is that adding some more features to a language by
extending the VM capabilities is usually not that hard).

I think it is a much bigger challange to find a good *conceptual*
framework that provides more flexibility. In this particular case, a
flexible MOP (Meta Object Protocol) could be a good candidate. (This
would not only parameterize message send, but also define how the slots
are organized (e.g., in a sort of array or in a hash-table), etc.)

Nathanael


> -----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 7:44 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: Eliminating superclass lookup in the VM (and 
> dynamic composition of behavior)
> 
> 
> 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
> > > >
> > > >
> > > 
> > > 
> > > 
> > 
> > 
> > 
> 
>