4 ms·

> If the message is delegated further, all questions about the values of variables or requests to reply to messages are all inferred to the object that delegate

> If the message is delegated further, all questions about the values of variables or requests to reply to messages are all inferred to the object that delegated the message in the first place. I'm not sure how the author jumps from that quote to: > When that object delegates to another, then any reference to "self" always refers to the original message recipient. Always. The high-order bit is that the delegating object can be interrogated for more information or context (and a reference to that object can be forwarded to further delegates), no? Why does that need to be implemented by re-binding whatever keyword or name an object calls itself to a different object?

galaxyLogic 9y ago
That is probably because what he and we are talking about here is the technical definition of "delegation". If you just call a method of another object and then that object perhaps but not necessarily sends some messages back to the original sender, to get further information, that could conceptually be seen as "delegation". But technically that's just normal (bi-directional) message-exchange. "Delegation" needs to refer to something more technically specific to warrant its existence as a technical concept.
- josteink 9y ago
  For languages which didn't have function-pointers as a first-class construct (like Java), you had to create another way to delegate functions between different objects. A way to encapsulate them, if you like. It may not seem novel now, but it was not obvious to everyone at that time that this was a possible design-pattern.
josteink 9y ago
From what I can tell, this is a whole lot of bickering about the difference between prototypical languages (like JS) and inheritance-based OO-languages (like C++/Java/C# etc). The Gand of four wrote Design patterns for the inhertance-based world, because that was what was churning out most business software and had the biggest need for some standard patterns and conventions. And they used (reused?) the word delegation to fit a useful pattern in a non-prototypical language. And AFACT that's his argument. That all modern OOP languages got it wrong. So they got delegation wrong too. And GOF got it wrong because the wrote it for modern OOP. Or did I miss anything?
mannykannot 9y ago
I had to take a couple of passes at that to figure out what the various referents were. This is just a summary of Lieberman's position, so I guess we will have to go to his paper to see the reasoning behind this position. As far as I follow it, the argument is that delegation means, in prototype-based OO (apparently the only context in which either author recognizes its use), that if an object has no method for handling a message that it has received, then it transitively searches through its prototypes for one that can handle it, and if found, the receiving object delegates the message to that prototype's method for handling. When that method handles it, however, it should do so in a way that is aware of the context of the object originally receiving the message, so that, for example, if both the receiving and handling object have a name, the handler should use the receiver's name if it needs a name in handling the message. If we assume that the methods reference the context they are working with through a variable called 'self', then passing the handling method a 'self' bound to the original message receiver (not necessarily the most recent delegator) will achieve this: any method calls or references the handler needs to make will go through the same delegation process, starting from the original receiver, and in so doing possibly, but not necessarily, ending up at a method from the same object as was picked to handle the original message. There may be the additional implication that this greatly facilitates composition, which is (it is claimed) preferable to inheritance, but I would think name collisions are a problem.

galaxyLogic 9y ago

That is probably because what he and we are talking about here is the technical definition of "delegation". If you just call a method of another object and then that object perhaps but not necessarily sends some messages back to the original sender, to get further information, that could conceptually be seen as "delegation". But technically that's just normal (bi-directional) message-exchange. "Delegation" needs to refer to something more technically specific to warrant its existence as a technical concept.

josteink 9y ago
For languages which didn't have function-pointers as a first-class construct (like Java), you had to create another way to delegate functions between different objects. A way to encapsulate them, if you like. It may not seem novel now, but it was not obvious to everyone at that time that this was a possible design-pattern.

josteink 9y ago

From what I can tell, this is a whole lot of bickering about the difference between prototypical languages (like JS) and inheritance-based OO-languages (like C++/Java/C# etc). The Gand of four wrote Design patterns for the inhertance-based world, because that was what was churning out most business software and had the biggest need for some standard patterns and conventions. And they used (reused?) the word delegation to fit a useful pattern in a non-prototypical language. And AFACT that's his argument. That all modern OOP languages got it wrong. So they got delegation wrong too. And GOF got it wrong because the wrote it for modern OOP. Or did I miss anything?

mannykannot 9y ago

I had to take a couple of passes at that to figure out what the various referents were. This is just a summary of Lieberman's position, so I guess we will have to go to his paper to see the reasoning behind this position. As far as I follow it, the argument is that delegation means, in prototype-based OO (apparently the only context in which either author recognizes its use), that if an object has no method for handling a message that it has received, then it transitively searches through its prototypes for one that can handle it, and if found, the receiving object delegates the message to that prototype's method for handling. When that method handles it, however, it should do so in a way that is aware of the context of the object originally receiving the message, so that, for example, if both the receiving and handling object have a name, the handler should use the receiver's name if it needs a name in handling the message. If we assume that the methods reference the context they are working with through a variable called 'self', then passing the handling method a 'self' bound to the original message receiver (not necessarily the most recent delegator) will achieve this: any method calls or references the handler needs to make will go through the same delegation process, starting from the original receiver, and in so doing possibly, but not necessarily, ending up at a method from the same object as was picked to handle the original message. There may be the additional implication that this greatly facilitates composition, which is (it is claimed) preferable to inheritance, but I would think name collisions are a problem.