Talk:Double dispatch

Latest comment: 19 days ago by 2600:1700:131:3B60:FCF5:588B:12EF:DA9B in topic Computational Efficiency Citation?

Drowning in (unnecessary) complexity edit

Who knows this "Eiffel" thing? Who cares about complex astronaut situations requiring hundreds of lines of code? I came to this page looking for ONE simple plain example and I got submerged with complexity. Can anyone please show in thirty lines of code the difference between single and double dispatch? Thank you. 2.228.6.10 (talk) 11:40, 5 February 2015 (UTC) — Preceding unsigned comment added by 2.228.6.10 (talk) 11:36, 5 February 2015 (UTC)Reply

Yes, this is a horrible example: not only is it too complex, it assumes knowledge that no-one who doesn't already know the dispatch model is likely to have. — Preceding unsigned comment added by 64.222.238.92 (talk) 15:56, 6 March 2018 (UTC)Reply

Why are the examples in an arcane language? edit

The examples in this article are in Eiffel which is a language I do not think very many people will recognize or know off the top of their head. Java or C++ examples would be a much better choice. Java examples would probably be the simplest choice since they avoid pointers, etc. — Preceding unsigned comment added by 146.115.148.149 (talk) 11:23, 16 June 2014 (UTC)Reply

I agree, this needs to be rewritten to something like Java, C# or C++. Dnesteruk (talk) 10:39, 25 August 2016 (UTC)Reply

Article needs a careful rewrite edit

I began to correct what appeared to be only minor errors, when I realized that this article basically needs a careful rewrite.

A few notes:

A compiler cannot statically compute the function pointer offset for a dynamically bound method.

The double dispatch pattern can be implemented in any language. It's meaningless to talk about languages that do or don't support double dispatch.

There is a runtime cost of double-dispatch, but it should not to be confused with the cost of dynamic method binding.

Basically, much of the article confuses two related, but distinct, concepts: dynamic method binding and the double dispatch pattern. In part, this confusion arises because the examples use a statically typed language, C++, where both issues are important. I would recommend using a dynamically typed language (e.g. Smalltalk or Python) to explain double dispatch. Since all method binding is dynamic in a dynamically typed language, there's no point of distiction, and the dynamic method binding won't obscure the double dispatch concept.

—The preceding unsigned comment was added by 164.223.72.6 (talkcontribs) 20:32, 5 July 2005 (UTC1)


I disagree with a statement above. It's certainly meaningful to talk about language support for double dispatch, or anything else. I can implement control and data structures, object-oriented programming and exception handling in assembly language. That doesn't mean assembly language has support for these things. This kind of ignorant statement slides toward the naive Turing equivalence argument: that any Turing complete language has the same support for doing everything that can be done in any other Turing complete language. That is a fallacy, because support has to do with expressiveness, not raw computability.

Multiple dispatch is a form of overloading. It's overloading based on a latent type, so it would not be wrong to call it dynamic overloading. C++ style overloading is based on manifest type only. That's the difference. Overloading would become multiple dispatch if the dynamic type of each argument were considered, whenever the argument is a reference to a base class.

The issues in this page are confused; it is asserted that overloading does one dispatch through a virtual table. That is false. Overloading has nothing to do with virtual tables. C++ supports overloading for non-member functions, and for static member functions. Virtual functions can be overloaded too, yes. What happens then is that the particular variant is first chosen based on the static argument list using ordinary overload resolution. Under overload resolution for object calls, the object is considered to be a hidden zeroth argument. Its manifest (static) type is used. If overload resolution comes up with a unique best candidate, then the function is called, and normal virtual dispatch takes place. By then, the parameters are no longer considered; they have been dealt with. Whatever overload gets called through the virtual table, it necessarily has that exact argument list. A virtual funtion overloads another only if the name and parameter signature match.

Another key difference between multiple dispatch and (C++) overloading is that C++ overloading has rules that can fail to come up with a unique candidate, thereby stopping the translation of the program. By contrast, in the Lisp object system, if there exist suitable primary methods that can satisfy a call, one will be chosen. Ambiguities are resolved using left to right base class precedence. If a D is derived from B1 and B2, it is "slightly more" a B1 than a B2. Only if no primary method can be found will the be an error: a run-time "method not found" condition.

In C++, it's possible to introduce a new overload function to a program which will make it invalid. That is to say, a program can contain some overloaded functions, and calls to them, which successfully resolve. It's possible to introduce a new function which ambiguates the call, so that the program can no longer compile.

—The preceding unsigned comment was added by 24.83.96.126 (talkcontribs) 18:52, 21 October 2005 (UTC1)


I failed to understand the concept of double-dispatch as well as the discussion you are having about it on this page. I am not a hardcore coder so I am not saying that your areguments are incorrect - what I AM saying however is that I came to this article as a novice programmer and did not get any value from it. And I am not getting more value out of your discussion on C++ overloading. Sorry.

You both seem like very intelligent people, so why not use your energy on discussing how the article can explain the double-dispatch concept to newcomers? Preferably explaining the basic concept WITHOUT any specific code or laguage to begin with (as I understand it double-dispatch is very generic in nature and not specific to any one language), and THEN moving on to a few code examples for 2-3 of the most popular languages around? —Preceding unsigned comment added by 87.59.85.94 (talk) 21:47, 15 February 2010 (UTC)Reply

SpaceShip example edit

I found that the code as presented didn't execute as expected: I had to add the following methods -

class SpaceShip {
	public:
	virtual void CollideWith(Asteroid& inAsteroid) {
 		 inAsteroid.CollideWith(*this);
	}
	virtual void CollideWith(ExplodingAsteroid& inAsteroid) {
 		 inAsteroid.CollideWith(*this);
	}
};

class GiantSpaceShip : public SpaceShip {
	virtual void CollideWith(Asteroid& inAsteroid) {
 		 inAsteroid.CollideWith(*this);
	}
	virtual void CollideWith(ExplodingAsteroid& inAsteroid) {
 		 inAsteroid.CollideWith(*this);
	}
};

bob towers. —The preceding unsigned comment was added by 82.153.33.97 (talkcontribs) 01:15, 7 February 2007 (UTC1)

This example seems to be copy/pasted from Scott Meyers book. Is he aware of that? 15.227.137.70 20:30, 11 April 2007 (UTC)Reply

I doubt that the C++ example is right edit

At the end of the example, which says: "Within ApolloSpacecraft::CollideWith(Asteroid&), inAsteroid is a reference, so inAsteroid.CollideWith(*this) will result in another vtable lookup. In this case, inAsteroid is a reference to an ExplodingAsteroid so ExplodingAsteroid::CollideWith(ApolloSpacecraft&) will be called..." This is very questionable. Actually it goes back to rely on a function overloading "ExplodingAsteroid::CollideWith(ApolloSpacecraft&) ", which is mentioned to be "static binding". Since the actual referenced type that is passed in is unknown until run-time, I don't see a reason that "ExplodingAsteroid::CollideWith(ApolloSpacecraft&)" will be called. — Preceding unsigned comment added by 12.184.144.28 (talk) 22:14, 10 October 2014 (UTC)Reply

This Article Needs Rewriting edit

All this is pretty much explained in short words at C2; and this article is so arcane and senseless that is should be fully rewritten. Vlad Patryshev (talk) 23:53, 23 April 2015 (UTC)Reply

I agree. An article with 20% explanations and 80% examples is not an encyclopedic article. Examples shall help to understand the matter and not be the core of the article. The fundamentals of the double dispatch need to be explained more deeply, with a language independent description of how it works. Then, everybody can't just put an unsourced code example in the favourite language: this is not compliant with wikipedia guidelines. Not to speak about a "classical example" with no reference of the language. I think wikipedia should not become a code-sharing platform. And if the examples are meant to stay, then they should be isolated in an overarching example section, and in a neutral alphabetic order of the language name, and not according to the personal preferences of the contributors.--Christophe (talk) 09:24, 5 July 2020 (UTC)Reply

Computational Efficiency Citation? edit

Firstly, thank you to the maintainer of this page. I found it very informational.

Secondly, is the agent model always more computationally expensive than its direct call counterpart as the article notes? Is that true for all double-dispatch implementations from a theoretical point of view or just in the Eiffel language? As somebody more familiar with Julia, my intuition is that multiple-dispatch should be fast.

In general this article could benefit from more citations. Lastly, contrary to the other contributors, I don't mind example-heavy articles for esoteric programming topics; however, they should be highly generalizable. 2600:1700:131:3B60:FCF5:588B:12EF:DA9B (talk) 17:01, 16 April 2024 (UTC)Reply