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