PARTS workbench (was both a standalone product and a part of VSE from
Digitalk cum ParcPlace-Digitalk cum CinCom) used the instance specific
feature extensively....If you pointed to a widget in the parts workbench
and added a script to it, the script was specific to that instance (and
copies you made of that widget).  There were a lot of interesting
deployments of PARTS systems (beer brewing realtime control was one of
my favorites, as was a railroad control and scheduling system)

-----Original Message-----
From: Andreas Raab [mailto:andreas.raab at gmx.de] 
Sent: Wednesday, December 11, 2002 2:44 PM
To: squeak-dev at lists.squeakfoundation.org
Subject: RE: Eliminating superclass lookup in the VM (and dynamic
composition of behavior)

Thinking about it, yup, that seems to be the way to do it. It allows the
developer to think in any terms he wants to (or rather in the terms
provided by the UI). I'd really like to hear more about how these
"arrays of method dictionaries" were used in practice. Were there any
(experimental or real) systems built that tried to use the added
flexibility at this level?!

Thanks,
  - Andreas

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of George Bosworth
> Sent: Wednesday, December 11, 2002 10:30 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: Eliminating superclass lookup in the VM (and 
> dynamic composition of behavior)
> 
> 
> 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
> 
> 
>