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

Stephen Pair spair at acm.org
Wed Dec 11 18:30:21 UTC 2002


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




More information about the Squeak-dev mailing list