Hi Stephen,

I will attempt the full VM build and image preparation this evening and let
you know how my Linux machine likes it.  As you know, I had difficulty with
the Forwarder changeset under Linux.  I am wondering if it may have been due
to my not running the image prep code you list here.

It strikes me that this may be an alternative to your proposal for
differentiating multiple versions of the same message.  If we proxy an
object reference, with a delegate, then we can pick up any overriding
implementations of a method for it's class, within that Module.  Instead on
overriding a superclass' implementation, we are overriding a class
implementation in an inner, more generic module, with an implementation in a
more specific module implementation.  In this way, don't extensions of
classes between modules look like Self-style inheritance?

I will post another more specific to my Module questions...

cheers,
Rob

> -----Original Message-----
> From: Stephen Pair [mailto:spair at advantive.com]
> Sent: Friday, August 17, 2001 11:48 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: [GOODIE] Delegation and Self like things for Squeak
> 
> 
> The following is copied from the web page: http://spair.swiki.net/21
> (which also contains screenshot).
> 
> -------------
> === Overview
> This change set adds delegation capabilities to the Squeak VM. It also
> extends some previous work on prototypes by Hans Martin Mosner to
> implement a Self-like (http://self.sunlabs.com) system within Squeak.
> 
> Delegation is the act of forwarding a message to another object, but
> maintaining the original receiver such that sends to self in the new
> method context will be directed back to the delegating object.
> 
> === Screenshot
> The following screenshot shows ProtoInspectors open on a family
> (literally) of objects. They are arranged according to their 
> inheritance
> hierarchy. Slots with an asterisk denote parent slots (their 
> behavior is
> inherited by the child). The image doesn't show it, but you 
> may have any
> number of parent slots.
> 
>  <<see web page: http://spair.swiki.net/21>>
> 
> === Implementation Details
> Two new bytecodes are added to the VM:
> 
> singleExtendedDelegateBytecode 
> doubleExtendedDelegateBytecode 
> (but the compiler has not yet been modified to generate these 
> bytecodes)
> 
> Several new primtives are added to support delegation and reflection
> 
> primitiveDelegate - added to Object as #delegate:, #delegate:with:,
> ...etc 
> primitiveDelegateArgs - added to Object as #delegate:withArguments: 
> 
> The following primitives allow a Mirror to reflect on objects without
> needing to send messages to the reflectee (this allows mirror to
> manipulate objects that may have a very lightweight protocol):
> 
> primitiveGetSlots 
> primitiveSetSlots 
> primitiveGetProtoBehavior 
> primitiveSetProtoBehavior 
> 
> The message lookup algorithm is also modified to search the 
> parent slots
> of objects whos class is an instance of ProtoBehavior. This allows for
> instance based, multiple inheritance.
> 
> Bytecodes accessing the internal structure of an object
> (pushReceiverVariable and kin) are modified such that the look to the
> "receiverStorage" object in the active context. In normal messages
> receiverStorage is identical to receiver, but in delegated 
> methods, they
> will be different.
> 
> You may create object that inherit behavior from normal Smalltalk
> instances (direct instance variable manipulation will affect 
> the parent
> object, not the child's slots).
> 
> Hans Martin Mosner's HmmProtoObject class has been dropped in favor of
> the Mirror class and a reflection based approach to 
> meta-programming in
> the spirit of Self. To add or remove slots or methods, you must use a
> mirror (unless you add methods to your instance). The 
> ProtoInpector now
> uses a Mirror to manipulate an object. This allows objects to be
> inspected and manipulated even if they have no behavior.
> 
> The VM has also been enhanced such that a recursive 
> #doesNotUnderstand:
> will not crash the image, but lookup the #doesNotUnderstand: on Object
> (and you will get a #doesNotUnderstand: on a #doesNotUnderstand:
> message). This was done because the likelyhood of 
> accidentally creating
> objects that don't understand #doesNotUnderstand: has increased
> dramatically with the introduction of ProtoBehavior.
> 
> There should now be enough support in the VM to implement a pretty
> robust implementation of Self within Squeak. It would be 
> really cool to
> see the Self tools for manipulating objects recreated in Squeak.
> 
> === Issues
> The compiler has not been modified in any way, shape or form to
> implement anything like the Self syntax. This means that doing certain
> things can be awkward. Additionally, this means that you must use
> #delegate: or one of it's variants in order to accomplish what Self
> calls a "resend." Also, only a directed resend is possible.
> 
> There is no way to store instance based source code, therefore, all
> methods appear in their de-compiled form. This is a pain.
> 
> 
> === Downloading
> There are three things that you can download:
> 
> 1. A bundle that includes a demo image, changes file, and a Win32 VM
> 2. Just the change set (you will need to compile your own VM 
> and follow
> the procedure below to get an existing image prepared to run on it)
> 3. Just the win32 VM (note, trying to run a base Squeak image 
> on this VM
> won't get you very far very fast)
> 
> If you are going to compile you own VM, you will need to load 
> the change
> set, and then execute the following code in a workspace to prepare the
> existing method contexts in your image:
> 
> 
> 
> MethodContext allInstances do: 
>   [ :ea | ea instVarNamed: #receiverMap put: ea receiver ].
> Smalltalk snapshot: true andQuit: true.
> 
> 
> 
> Then, you should have an image that will work on your new VM with
> support for delegation.
> 
> Enjoy!
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20010820/ab172dff/attachment.htm