That's great! (the beer part)

Someone said to me once that they really disliked exposing optimized
structures to Smalltalk code.  That notion has kind of  been wandering
around in my head as I think about this...the approach taken in
Smalltalk/V would appear to be one such case (as is flattening the
method dictionary).  I wonder if anyone else has an opinion on that
issue.  I'm inclined to believe that it's not valid (when treated as a
general rule of thumb).  

If I understand the direction of things to come...with dynamic
compilation, we should eventually have systems where there is no
traditional VM...everything that we consider to be VM code today would
be written in Smalltalk (or whatever language) and dynamically
translated to machine code.  In that case, there is no VM/Smalltalk
distinction, so you couldn't hide the optimizations in the VM even if
you wanted to (because there is no VM).

And that leads leads to another thought...for a long time, we've tried
to build the VM such as to protect a person working in Smalltalk from
being able to crash the system (which of course is not a attainable in
any practical sense)...but, without a VM, we will need another mechanism
for layering (or securing) the system...which I guess feeds into
"Subjective Squeak" thread...so I'll stop with that.

Anyway...Andreas, this sounds like a possible solution to your instance
specific behavior needs in eToys and Croquet (and if you add delegation,
it should be quite powerful).  But then again, if you are going to make
that radical of a change, you might do just as well to go all the way
and do something along the lines of Self's object memory.

- Stephen

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