Many, many thanks Stephen.  It is clearly an issue with my VMBuilder in 3.1
land.  Time to re-evaluate those Plugins and see what is different.  I
haven't tried your VM yet, but will when I get home to my Linux box. 

That is the Forwarder implementation if we set the target's receiverMap to
the Forwarder.  Identity maintained!  For this other bit that I want, to
remove the ProtoObject protocol and make it a minimal impact piece, see my
response to Jecel (although you have heard it all before :). 

cheers,
Rob 

> -----Original Message-----
> From: Stephen Pair [mailto:spair at advantive.com]
> Sent: Tuesday, August 21, 2001 5:49 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: [GOODIE] Delegation and Self like things for Squeak
> 
> 
> Rob,
> 
> I've compiled a Linux VM with RedHat 6.2, it seems to check 
> out OK.  The
> zip file now just contains an image and changes file.  So, try getting
> that and the linux VM and see if you have better luck.  I've release
> Rev.4 of the Delegation change set which fixes a couple of things and
> cleans up a couple of other things.
> 
> >I does start to seem like just an extended Proxy, with the ability to
> install methods.  This is very nice, but it may not be the 
> thing I think
> I need.  Having instance methods, or rather reference-scoped 
> methods, is
> half of the solution.  The other bit is a truly stateless, first-class
> reference, that maintains identity, but allows for method override and
> lookup notification.
> >
> >I believe it would depend on how we bring Forwarder/ManagedObjects
> support using this mechanism.  The forwardee would be a parental slot,
> that would have it's protocol delegated too.  How would we do pushSelf
> substitution in this scheme?  I imagine that the receiverSelf for the
> forwardee would be the forwarder prototype.
> >
> >I understand about the storage overhead (receiverMap) - that 
> sucks.  We
> need a first class reference object, that the VM knows how to
> manipulate.  
> >
> >For my desire to have managed objects (managing message 
> sending), this
> provides a mechanism to override methods at the instance level in the
> proxy prototype.  I would have to compile/install all methods 
> I want to
> intercept, with the correct intercept code.  So for my needs, I would
> rather have a way to either:
> >        1 - have a message lookup notification, with the ability to
> either cancel further lookup, or choose not to resend
> >        2 - have the ability to install custom lookup methods for an
> instance, and have the VM check and activate custom lookup when a send
> occurs.
> >Another alternative is a notification whenever lookup is 
> changing it's
> scope to a superclass or parent, as the case may be.
> >- Rob
> 
> Rob...Try this:
> 
> - create a new prototype
> - set it's superclass to ProtoObject (necessary to peacefully exist in
> squeak)
> - remove all slots except one, which is *not* a parent slot 
> (let's call
> it "target")
> - remove all methods
> - add the following method:
> 
> -------
> doesNotUnderstand: aMessage
> 	"Do your stuff here"
> 
> 	^target delegate: aMessage selector arguments: aMessage
> arguments
> -------
> 
> Does this not give you the power to intercept all messages and do what
> you need to do?  In effect, this is an object with a completely
> customized message response scheme (with the exception of the
> ProtoObject methods...which could also be eliminated if a few 
> tweeks to
> the base Squeak stuff). 
> 
> The reason we don't have target as a parent is because the VM would
> attempt to go ahead and delegate the message before you had a 
> chance to
> intercept it.
> 
> - Stephen
> 
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20010821/1a4c8761/attachment.htm