Talk:Delegation (object-oriented programming)

Does explicit object passing count as delegation, or not?

The introduction of the article says

   Delegation can be done explicitly, by passing the sending object to the receiving object, which can be done in any object-oriented language; or implicitly, by the member lookup rules of the language, which requires language support for the feature.

But the Language Feature section says

   Hence it is the original receiver entity that is the start of method lookup even though it has passed on control to some other object (through a delegation link, not an object reference)."

This is confusing. Why is the definition of delegation more restrictive here than in the introduction? Maybe the Language Feature section is more restrictive because it's talking exclusively about delegation in OO languages that have special support for it. If so, it would be less confusing if that were made clear. For example, the beginning of the Language Feature section could be changed from

  The short definition is that delegation defines method dispatching...

to

  In languages that specifically support delegation, method dispatching is defined...

This would make clear that the whole paragraph refers to implicit delegation supported by the language.

Alternatively, the section title "Language feature" could be elucidated to "Delegation as a language feature", though I don't think that's quite as clear.

Or maybe the reason it says "not an object reference" is that when explicit delegation is done by passing an object reference, method lookup / dispatching is not automatically affected in the way described. Huttarl (talk) 11:21, 31 July 2016 (UTC)

I made some changes to clarify, and removed the "contradiction" template. I think this is fine now. Huttarl (talk) 22:10, 1 August 2016 (UTC)

JavaScript

JavaScript implements delegation, maybe that should be mentioned.

In JavaScript, to parse foo.bar, the compiler first searches the list of object foo's properties for one named "bar", then if not found the list of properties of object foo's prototype, then recursively to the Object built-in object prototype which has some identifiers shared by all objects, such as toString, a method that returns a string description of the object. If the string "bar" was not found, it returns the "undefined" object; else if the found property holds a primitive, it returns its value; if it is an object, it returns a reference to it. In JavaScript, a function is an object (which you can call). A method is an function in which the identifier "this" refers to the object it is a property of.

var A = {}; // same as A =  new Object()
var B = ( function() { 
        var F = function () {};
        F.prototype = A;
        return new F();
        }());
// from JavaScript 1.8.5 Object.create(A) returns same as above code
// now object A is in the lookup chain for object B's refinements
A.counter = 0;
A.separ = ": ";
B.separ = ", ";
for ( A.counter = 0 ; A.counter < 10 ; A.counter++) {
     document.write(B.counter + B.separ); // 0, 1, 2, 3, 4, 5, 6, 7, 8, 9,
}

That's delegation, isn't it? I don't know where to place this example in the page. I don't quite get the structure. There's a mention of JavaScript and ECMAScript, but the main example refers to language that do not implement prototype-based inheritance.

In several places the article text refers to methods. Is this part of the definition of delegation? JavaScript/ECMAScript treats fields and methods alike. The above example could be written with a closure and methods:

var counter = (function () {
        var n = 0;
        return {
            increment: function () {n++;},
            get: function () {return n;}
            };
}());
counter.separ = ": ";
var myObject = ( function() { 
        var F = function () {};
        F.prototype = counter;
        return new F();
        }());
// from JavaScript 1.8.5 Object.create(Counter) returns same as above code
// now object Counter is in the lookup chain for object B's refinements
myObject.separ = ", ";
while (counter.get() < 10) {
     document.write(myObject.get() + myObject.separ); // 0, 1, 2, 3, 4, 5, 6, 7, 8, 9,
     myObject.increment(); // same as counter.increment()
}

I shouldn't say that makes things any clearer; but if the point is inheriting methods, that's it.

Polbrian (talk) 08:06, 24 September 2011 (UTC)

Additional cross reference

I don't see a link on this page to Observer pattern. I'm new to this stuff, but aren't these two topics intrinsically related? Kmote (talk) 22:10, 15 December 2008 (UTC)

Old definition

Shouldn't the old definition go under the modern one? Most people don't read more than one page, which would mean only the old definition is read. - September 26th 2005

Good point. Wouter Lievens 10:20, 26 September 2005 (UTC)

Third Definition

The third definition, as given in [Taivalsaari, 1996] is missing. Shall I add it? Wouter Lievens 19:37, 1 May 2005 (UTC)

Now that I think of it, the definition is equivalent. Wouter Lievens 14:35, 11 May 2005 (UTC)

Language Feature example wrong?

This discussion has been closed. Please do not modify it.
The following discussion has been closed. Please do not modify it.
I don't get this. If a in class B were a usual field, this in A::foo() would refer to the a object, so you'd get "a.bar" printed. With the delegation language feature, it should be "b.bar", since this still refers to object b. Giese 09:37, 27 September 2006 (UTC) Giese, even though no-one has responded to your concern in nearly 3 years, I think you are right. When b.foo is called, (class A).bar should start lookup (Smalltalk style) at b.bar which is B.bar, and thus print("b.bar") I may be wrong, but my first impression is that the Java/C# example contradicts the text. If I understand correctly, the text insists that the method binding is done at run time, but the example appears to bind class B (the lookup of B.foo) to class A (looking up A.bar) at compile time. Have I misunderstood the Java/C# pseudocode? Could the article be expanded a little to explain how the program can delegate B.foo to different methods (such as C.foo and D.foo) depending on a run time delegation link, depending on the class/state of a when new B(a) is called) at run time? --Hroðulf (or Hrothulf) (Talk) 08:22, 29 June 2009 (UTC) I don't know anything about this, but I also think Giese is right. The page Consultation_(object-oriented_programming) says that one of the main differences between delegation and consultation is that delegation has "late binding of self". This term is explained in Fig. 1 of the paper "Intersecting Classes and Prototypes", and it seems like it is consistent with Giese's suggestion. The example in the article seems to be an example of consultation. Also, this article should make reference to and define "late binding of self". A start: In delegation, when the delegator object is called, the delegator calls the delegee code. Late binding of self means that if the delegee code refers to "self", then that refers to the delegator object, not to the delegatee object. Bayle Shanks (talk) 01:40, 11 December 2009 (UTC) Yes, Giese is absolutely right. The article has been wrong for over 9 years(!!) and I'll now correct it.--greenrd (talk) 16:07, 4 January 2015 (UTC)

Hard to understand

This page needs some cleanup work to make it easier to read. I can't understand half of what its talking about. This should be readable to people who have never heard of a delegate. Fresheneesz 00:18, 22 November 2006 (UTC)

Would make more sense if the first example were replcaed with the better one from Delegation pattern.

Would make even more sense to me if the top example actually didn't rely upon a "delegate" keyword to function. There should not be a pseudo code in this example, there should be several small examples from other languages. Java (of course) doesn't produce what the example says it should produce.Tgm1024 (talk) 15:24, 20 January 2019 (UTC)

Merge with Delegation pattern

This article talks at length about the Delegation pattern, yet Delegation pattern already has its own node. Shouldn't they be merged? --Devnevyn 12:45, 11 August 2007 (UTC)

I second this. This page is not very clear to me even as one who already understands its subject. 76.187.248.215 (talk) 09:07, 15 July 2008 (UTC)

Agreed. Would make more sense if the first example were replcaed with the better one from Delegation pattern too. — Preceding unsigned comment added by 122.148.41.172 (talk) 13:37, 18 November 2012 (UTC)

This has gone on for so very long now as a crummy page. I would recommend its deletion, but frankly, I don't have the time to go through the wiki-rigmarole to see it through. It provides no benefit that I can see. Am I wrong? Tgm1024 (talk) 15:27, 20 January 2019 (UTC)

Merging with Delegate (.NET)

I am removing the merge proposal, as a delegate object as per .NET terminology is deeply different from the Delegation design pattern presented here. - 62.101.126.215 (talk) 16:08, 21 January 2008 (UTC)

"so-called self-calls"

Most commonly, [delegation] refers to a programming language feature making use of the method lookup rules for dispatching so-called self-calls as defined by Lieberman in his 1986 paper "Using Prototypical Objects to Implement Shared Behavior in Object-Oriented Systems

I can't find the term "self-call" on wikipeia or in the paper ( http://web.media.mit.edu/~lieber/Lieberary/OOP/Delegation/Delegation.html ), and a paper reference rather than an explanation is pretty horrible. Perhaps a common example would help, (if I've understood this correctly at all) "..feature, such as Java's virtual method calls, making use of..". //22oct2011 — Preceding unsigned comment added by 65.31.112.33 (talk) 18:53, 22 October 2011 (UTC)

    ==definition==
    in (Wikipedia's) "Glossary of Unified Modeling Language terms" it is defined as a "Message from an Object to one of its own Methods".
    This could be edited into the link but I forgot how to do it. lifeform (talk) 06:44, 3 March 2014 (UTC)

Distinction from .NET delegates

I would suggest the reference to .NET delegates be reworded to make it clear it's a completely different concept, which has its own page at Delegate (CLI). Burt Harris 20:32, 20 May 2014 (UTC) — Preceding unsigned comment added by Burt Harris (talk • contribs)

Page should be split and deleted

This article is a mess as it is about 3 different things - with some unsubstantiated zealotry about which is the "true" version of delegation thrown in for good measure! I think the content from this article should be split into 3 separate pages:

• Delegation (dynamic inheritance) - not sure if that is the best terminology, maybe there is a better alternative term to "delegation" for this?
• Delegation pattern (already exists)
• Delegate (CLI) (already exists) - this should also cover multicast delegates

I don't know what "unsubstantiated zealotry" was in the article before, but the distinction between "true delegation" and "simple forwarding" is substantiated by the GoF Design Patterns book (p. 21), and often repeated by others. I think it's reasonably well established. There are sources that don't distinguish the two, but in my limited experience they are less definitive.

and then those 3 pages should be linked from Delegation (disambiguation). This page could then be converted into a redirect to Delegation (disambiguation).--greenrd (talk) 16:27, 4 January 2015 (UTC)

Done, in 714620119, moving the specific page to Delegation (object-oriented programming), having Delegation (programming) link to a section in the disambiguation page Delegation (disambiguation), and then cleaning up (moving CLI-specific content out and rewriting lede) in 714627891.

The notions of delegation (evaluating a member of one object in the context of the originating object), forwarding, CLI delegates, and the delegation pattern are now all clearly separated.

This makes a lot of sense to split and distinguish, as demonstrated by the many threads and merge/split proposals on this talk page, and the ambiguous use in practice.

The narrow, technical sense of delegation (now the content of the page) is as fundamental in prototype-based programming as inheritance is in class-based programming. It is fundamental to the seminal Self language and the widely used JavaScript language, and has been a topic of considerable academic research over 30 years so far. It thus clearly merits its own page.

—Nils von Barth (nbarth) (talk) 22:30, 10 April 2016 (UTC)

Clear and consistent use of term "receiver"

In the first paragraph of the intro, "receiver" and "receiving object" mean the delegate (a.k.a. delagatee). In the second paragraph, it seems to mean the same thing. But later on "*original* receiver" is used to mean the delegator object (which received the original method call). This is a little confusing. But some other sources use just plain "receiver" and "receiving object" to mean the delegator, e.g. the GoF Design Patterns book (p. 20), and Cocoa documentation (https://developer.apple.com/library/ios/documentation/General/Conceptual/DevPedia-CocoaCore/Delegation.html). The article Delegation_pattern#Definition describes this difference of usage, and clarifies how that article uses the terms:

 Note that this article [i.e. Delegation_pattern] uses "sending object/receiving object" for the two objects, rather than "receiving object/delegate", emphasizing which objects send and receive the delegation call, not the original call.

Searching online, it seemed that the weight of usage is on the side of the GoF Design Patterns book, but not overwhelmingly so. How should this article (Delegation_(object-oriented_programming)) keep the usage clear? Options I can think of:

• Be consistent with the Delegation_pattern article, use sender/receiver terminology, and clearly state what these mean and how they differ from other common usage
• Use the GoF Design Patterns terminology, and clearly state what these terms mean and how they differ from other common usage
• Use unambiguous terms like delegator and delegate. Huttarl (talk) 22:10, 1 August 2016 (UTC)

This page needs an expert in a) delegation, and b) writing

I agree with the previous comments that this page is incomprehensible, diving immediately into details without actually explaining what the concept of delegation is. I think of it as turning over responsibility to, or deferring to, another, but I certainly can't get that out of this article. — Preceding unsigned comment added by Mprogers (talk • contribs) 15:04, 30 August 2020 (UTC)