[GOODIE] Delegation and Self like things for Squeak

Withers, Robert rwithers at quallaby.com
Tue Aug 21 18:18:52 UTC 2001


(All, sorry about the HTML; I am unable to turn it off with my mail
client...Outlook 2000 - grimace)

Stephen, I did manage to compile and test with a converted image.  I got a
walkback when first sending ProtoBehavior class>>#lobby.  It blew up in the
Mirror method that calls #primitiveGetProtoBehavior.  I have included the c
source, below, that my interpreter generated, in case it was different than
yours or you happen to see something.  Note that this base prototype object
is unable to #printString, for the same reason I believe.

> Withers, Robert wrote:
> >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.
> 
> Possible.  There are other problems with the Forwarder stuff.  Squeak
> seems to expect all objects to natively respond to at least the
> ProtoObject protocol for some things that it does (like 
> scanning for all
> references and such).  As soon as I began to address those issues, I
> realized that I could do everything I needed with a more generalized
> delegation scheme...so, the delegation stuff supercedes the Forwarder
> code (I'll make a note of it on the website).

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.

> >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?
> 
> What about identity comparisons?  Seems like that would cause trouble.
> How would the compiler be able direct a message to it's 
> special wrapper
> instance instead of the real object?  Also, it would add a good bit of
> storage overhead.

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

int primitiveGetProtoBehavior(void) {
    int object;
    int oop;
    int sp;
    int oop1;
    int ccIndex;

	/* begin stackObjectValue: */
	oop1 = longAt(stackPointer - (0 * 4));
	if ((oop1 & 1)) {
		/* begin primitiveFail */
		successFlag = 0;
		object = null;
		goto l1;
	}
	object = oop1;
l1:	/* end stackObjectValue: */;
	if (successFlag) {
		if (!((fetchClassOf(fetchClassOf(object))) ==
(longAt(((((char *) specialObjectsOop)) + 4) + (49 << 2))))) {
			successFlag = 0;
		}
	}
	if (successFlag) {
		/* begin pop:thenPush: */
		/* begin fetchClassOf: */
		if ((object & 1)) {
			oop = longAt(((((char *) specialObjectsOop)) + 4) +
(5 << 2));
			goto l2;
		}
		ccIndex = (((unsigned) (longAt(object))) >> 12) & 31;
		if (ccIndex == 0) {
			oop = (longAt(object - 4)) & 4294967292U;
			goto l2;
		} else {
			oop = longAt(((((char *) (longAt(((((char *)
specialObjectsOop)) + 4) + (28 << 2))))) + 4) + ((ccIndex - 1) << 2));
			goto l2;
		}
	l2:	/* end fetchClassOf: */;
		longAtput(sp = stackPointer - ((2 - 1) * 4), oop);
		stackPointer = sp;
	}
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20010821/3b61db1d/attachment.htm


More information about the Squeak-dev mailing list