Folks --

There is a cooler and most interesting way to approach all this. Much of
the seminal work was done around the late 70s in PARC Smalltalk by Ira
Goldstein and Danny Bobrow -- it was called PIE: Personal Information
Environment -- and they have been written up as PARC Blue Books (as noted
by Mike Klein previously to the Squeak list) ; *and* they can sometimes be
obtained from PARC.
     The basic idea is to have an object made up of multiple perspectives
e.g. a given object could have the perspectives of being an employer, an
employee, a father, a son, etc., *and* the perspective of being an object.
The internal representational strategy they used was to let a logical
object be made of as many Smalltalk instances as were needed, especially if
the perspectives were disjoint enough to give fits to simple-minded
mulitple inheritance schemes.

I have been a big fan of this general approach since Goldstein got it
running. There are also a wealth of other terrific ideas in their papers.

Cheers,

Alan

-----


 At 12:03 AM -0000 1/3/99, Vassili Bykov wrote:
>From: Stefan Matthias Aust <sma at kiel.netsurf.de>
>>I wondered how easy (or difficult) it would be to add support for multiple
>>superclasses (aka parents) to Squeak. I think, there's just one method
>>Interpreter>>lookupMethodInClass: which would be affected by the change.
>
>
>It is not that simple, at least not for the general case (i.e. with no
>limitations on the superclasses).  The trickiest thing is the instance
>layout.  Traditionally, instance variable access is compiled as direct
>indexing into an instance.  MI requires more hoops to jump.  Here is an
>example:
>
>Suppose you have two subclasses of Object: A, with an instance variable a;
>and B, with an instance variable b.  Access to both these variables in
>methods of A and B is compiled as accessing an instance variable at index 1.
>In instances of C, one of the two inherited variables ends up at index 2,
>meaning the compiled methods of the class it comes from cannot be used.
>
>Perhaps the simplest image-level solution would be to copy the inherited
>compiled methods into the subclass'es own method dictionary, adjusting the
>instance variable indices in the methods.  (This "method propagation" also
>has to be done later as the superclass's methods are added or modified).
>
>Alternative solutions would need the VM support.  One possibility would be
>for instance variable access to use, instead of an absolute index into an
>instance, an index relative to some base value.  The base would be
>determined at the runtime depending on the actual class of the instance, and
>on the class where the method that accesses the variable was defined.
>
>--Vassili
>
>--
>Vassili Bykov
>The Object People
>www.objectpeople.com