[Squeak-e] Programming the VM

[Robert Withers]

On Monday, February 3, 2003, at 12:50 PM, cg at cdegroot.com wrote:

> Mark S. Miller <squeak-e at lists.squeakfoundation.org> said:
>> "after the fact" would be bad. You'd be in a very weird state until 
>> it was set.
>>
> Hey, nothing that some loose references to quantum mechanics cannot
> solve ;-)
>
>> Otherwise, yes, exactly. Or, at least, it has to point at an object 
>> which is
>> in one-to-one correspondence with the parent 'machine', and which 
>> enables
>> this parent to open it up (ie, obtain an instance of Lex's 
>> ObjectInspector
>> on it) iff the object is indeed a child of this parent. I need to 
>> explain
>> the KeyKOS/EROS branding mechanism.
>
> Ok. My gut feeling is indeed that this is better than dynamic scoping.
> So we need an extra slot. Time to bring in the VM hacking squad ;-)

I think there are quite a few VM hacking squad members with us.   :-)

I'll point out that I am using one of the compactClassIndices for the 
MessageRedirector class.  This is the mechanism that pops message 
lookup into my context classes, and that is how I have implemented 
eventual references and promises.  Any message sent to an eventual 
reference will be eventually sent.

The next step I had in mind was to actually shove these contexts into 
the VM, so they weren't accessible in the image - it would require a 
special, MOPed Inspector to peer inside them.   This is my attempt at 
providing opacity.

Look at MessageRedirector (or MessageRedirectorProxy for non 
redirection VMs), Redirectionmanager and the ReferenceContext.  To get 
them to somewhat behave, I have a set of immediateCall selectors.

Now I have also used this context approach to implement a Mixin 
pattern, and more generally, i think that wrapping references in the VM 
allows one to define all kinds of auxiliary services.   It is a managed 
reference.  It could including this concept of a machine and the 
environment and parent-child relationship it models, if I am following 
correctly.

Inspectors on eventual references don't work especially well.  It has 
great difficulty in defining DoIt methods on the class side of the 
inspected object, because it keeps redirecting the #class method...  
:-)     It's like a greased pig!

cheers,
rob