[self-interest] design patterns

[Jecel Assumpcao Jr]

On Friday 03 January 2003 21:39, James McCartney wrote:
> One thing about using delegation for something like Chain of
> Responsibility: If you've delegated to a parent and that parent has
> its own methods and state, then that parent may want to have self
> refer to the parent instead of the original receiver in order that
> there are no unintended naming conflicts with other parents of the
> receiver or the receiver itself. How is this normally dealt with?

I would say that this is not normally dealt with. You know the old joke:

 "Doctor, it hurts when I do this."
 "Then don't do that!"

You avoid the problem by a careful selection of method names so there is 
no conflict. Yes, I know that this is impossible in the general case. 
But I am not sure changing the meaning of "self" will help that much.

  obj1 = (| chain* <- (| m1 = (m2+1). m2 = (42) |).
                 m3 = (m1/2).
                 otherParent* = xxx
  |)

I am supposing you are worried that obj1 might inherit a different "m2" 
from otherParent and want to force "m1" to call the one in the chain 
object and not any other. One solution is to use directed resend:

             m1 = (chain.m2+1)

though this will only work if all children refer to this object via a 
"chain*" slot and it will fail if the method is invoked on the chain 
object itself. Another issue is that "self" is only changed in the 
lookup of "m2" and any messages sent inside "m2" will use obj1 as 
"self" instead. That might be what you want, but I suspect it isn't.

Explicit delegation will change "self" for all further sends inside the 
invoked method:

           m1 = (chain m2+1)

but, once again, we are counting on a particular structure in the 
children. More generic solutions will be very awkward and involve 
reflection, while simpler solutions are possible for particular cases 
(a global oddball object normally has a name that it can use to refer 
to itself, for example).

-- Jecel