Talk:Double dispatch

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computer science (Rated Stub-class)
WikiProject icon This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Stub-Class article Stub  This article has been rated as Stub-Class on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.

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. (talk) 11:40, 5 February 2015 (UTC) — Preceding unsigned comment added by (talk) 11:36, 5 February 2015 (UTC)

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 (talk) 11:23, 16 June 2014 (UTC)

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

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 (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 (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 (talk) 21:47, 15 February 2010 (UTC)

SpaceShip example[edit]

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

class SpaceShip {
        virtual void CollideWith(Asteroid& inAsteroid) {
        virtual void CollideWith(ExplodingAsteroid& inAsteroid) {

class GiantSpaceShip : public SpaceShip {
        virtual void CollideWith(Asteroid& inAsteroid) {
        virtual void CollideWith(ExplodingAsteroid& inAsteroid) {

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

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

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 (talk) 22:14, 10 October 2014 (UTC)

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)