Stephen,

Great stuff!  I'm very excited by your work, especially as a mechanism for
delegation.  I am currently using the Trampoline object, that I think you
originally developed, Stephen.  I am unsure of how the delegation mechanism
would work with this forwarder, so please continue the ramblings at the
bottom.

comments below...


Anthony Hannan wrote:

>Stephen Pair <spair at advantive.com> wrote:
>> We must ensure that all references to self in the methods of a 
>> forwardee object are actually referring back to the instance of the 
>> forwarder (thus,references to the forwardee can be controlled).
>
>I assume your only doing this for identity since obviously the message
sends will come back to the 
>same forwardee.  But what about (Forwarder on: anObject) == anObject?
It will return false.  
>Changing identity just in the delagated method is not good enough.

[Stephen said:..]
Correct...however, for my purpose, it is good enough.  I'm only
maintaining references to the forwarder and the only reference to the
real object is in the forwarder.  If you have a reference to the
forwarder, why would you ever need to keep a reference to the real
object, except in the forwarder.

[rob - identity between forwarder and forwardee]
Should they be identical?  I imagine it would depend on the aspect of
identity one is interested in.  I agree that it is confusing to think of
this identity comparison between a mixed aspect/proxification of the core
object.

<big snip>

[Stephen said:..]
Also I think this design also allows for delegation...all that's needed
is a delegated send bytecode and/or primitive.  The forwarder is a
delegator (but it always blindly delegates everything it receives).
But, delegation would be fairly in-efficient in this design because you
would need to do an custom message look up and delegation in
#doesNotUnderstand: (or create methods whose only purpose is to
delegate)...what would really make it powerful is the ability to define
and plugin specialized message lookup algorithms.  I wonder if you could
desing the system such that the VM looks for a specialized lookup
algorithm in the Class, if it doesn't find one, it uses the default, if
it does find one (by finding a selector), it invokes that method to
locate the selector.  The custom "method lookup" method could optionally
be implemented as a primitive for better performance.  Anyway...I'm
rambling now.

[rob - delegation hooks]
This is where I am a bit confused about how this may work in practice.  I
believe your usage was to coalesce the reference to a changable object,
which would be polymorphic in protocol, to avoid the cost of a #become:.  Is
this right?   If I were to use a delegation model, or a managed object
model, then I think the forwardee is the delegator or manager.  This still
results in the same identity of self issue between the manager and the
managee.  I don't think DNU would work at the manager for this reason, given
that they are serially composed.  What if we make the manager and the
forwardee siblings in the Forwarder.  Then the normalSend primitive could
activate the manager with the following:
	#preActivateMethodSelector: aSelector withForwarder: aForwarder	
	#postActivateMethodSelector: aSelector withForwarder: aForwarder
Unfortunately, I think this requires a callback mechanism from the VM,
because we really want the same context on the Smalltalk stack, right?
Perhaps we instrument the byte codes, with a new activation prolog and
postlog, so even a primitive method call would work.

How could we do this?  As an example, I use the Trampoline to asynchronously
send messages, and I manage them by generating a Future and registering
handlers for the normalReturn/exceptionalReturn, before I send the message
asynchronously.  Another example would be a remote Delegator. 

-Rob

- Stephen



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20010725/3ccb8ebc/attachment.htm