Talk:Multiple dispatch

message: Multimethods != multiple dispatch. Multiple dispatch is a broader concept. Multimethods are just a syntax construct and just one way of implementing multiple dispatch. Other ways are chains of virtual methods (as in Visitor pattern) or instanceofs. Unnamed666 (talk) 12:42, 13 October 2014 (UTC)
thread_title:  Let's divide the article into two articles: Multimethods and Multiple dispatch 

message: The C++ example with templates does not implement double dispatch. It implements something akin to function overloading; but since all the arguments are dispatched upon statically, this is certainly not double-dispatch. In fact, the page for double dispatch explicitly points this out and describes how to implement double dispatch in C++ using the visitor pattern, and it also states explicitly why using function overloading does not achieve double dispatch.
If I hear no objections, I will remove the C++ template example from the page in a while.
74.125.57.33 (talk) 10:17, 17 February 2010 (UTC)
thread_title:  Incorrect C++ Template example 

message: Erik Meijer (one of VB9 designers) claims that Visual Basic 9 has support for multimethods, here and here. I don't know VB9 syntax, but it would be cool if someone should provide an example and clarify it. —The preceding unsigned comment was added by 161.53.243.217 (talk) 08:41, 22 February 2007 (UTC)
thread_title:  VB9 multimethods 

message: This article contains a sore lack of critique of multiple dispatch as a technique. What are the pros and cons of it? RyanTMulligan 23:46, 9 June 2007 (UTC)
thread_title:  Critique? 

message: Multiple dispatch is often essential in software engineering like Visitor pattern. When you have a very dynamic and potentially extensible system where user defined types need to interact with each other in a polymorphic way, multiple dispatch provides the most flexible and intuitive solutions. Even Bjarne Stroustrup admitted that he rejected multi-methods with regret because he couldn't find an acceptable way to implement it in c++. 
Cons of multiple dispatch are that its harder to prove type safety, incurs atleast some overhead at run-time (to determine the best method to dispatch) and possibility of message ambiguity at run-time.
Considering that Java and .Net are providing more run-time type-checking capabilities with each new version, the small  overhead in multiple dispatch should not be a limiting factor anymore. I truly think languages could benefit hugely by implementing multiple dispatch.
:It's incorrect that multiple dispatch inevitably incurs runtime overhead.  If the types are known at compile time, then it is often possible to perform the dispatch entirely at compile time.  e.g. the Julia language has dynamic multiple dispatch, which occurs at runtime in cases where the types aren't known, but often occurs at compile-time because typically the types are known to the compiler.  (When a function is called with a given argument-type signature, Julia JIT-compiles a specialized version for those argument types, and this includes compile-time dispatch, and sometimes even inlining, of any functions called within that function if possible.)  Because of this, Julia uses multiple dispatch even for something as basic as + (addition) on built-in numeric types (e.g. hardware integers), without incurring runtime overhead (attaining near-C performance for typical code). — Steven G. Johnson (talk) 15:33, 13 July 2017 (UTC)
thread_title:  Re: Critique? 

message: Would it be useful to note the difference between static types and dynamic types (and how multiple dispatch operates on the dynamic, aka run-time type) before the C++ section?  Text such as When working with languages that can discriminate data types at compile-time, selecting among the alternatives can occur at compile-time. makes it unclear as to whether we are talking about static types or dynamic types.  The above would seem to indicate that any statically typed language that allows function overloading would allow multiple dispatch, but this is not the case.  In fact, is the above actually true?  How could one always determine run-time data types at compile time?
Labreuer 15:41, 29 October 2007 (UTC)
thread_title:  Static types vs. dynamic types 

message: There seems be nothing that prevents multimethods from violating strong encapsulation of objects.
Strong encapsulation of objects plus unforgable references are the base assumption that all of object-capability based security rests on.
I am mostly in faviour of representing objects via message passing and closures (procedures with lexical scoping) as that shunts the whole dispatching desicions proplem to the called object. How that dispatch is resolved is then handled on object by object bases. (Interface and implementation inheritenche, polymorphism of methods and all that stuff)
--Zarutian (talk) 19:17, 14 May 2009 (UTC)
thread_title:  Object-capability security considerations 

message: The introductory paragraph currently says
:Multiple dispatch or multimethods is the feature of some object-oriented programming languages in which a function or method can be dynamically dispatched based on the run time (dynamic) type of more than one of its arguments. This is similar to function overloading, which is statically dispatched based on static types.
This is variously incorrect.
Multiple dispatch simply means there's dispatch, and it's not single dispatch.
In contrast to the definition given, multiple dispatch can be done in functional non-OO languages (eg), can occur at compile time, and can also depend on:
* the number of arguments,
* the static types of arguments,
* argument values rather than types (predicate dispatch),
* the names of arguments (in languages with named argument passing),
* the return type expected,
* or combinations of these.
Incidentally but similarly, function overloading can occur at runtime, and be based on dynamic type, and/or on expected return type.
The current introductory definition is quite misleading.
I propose the introductory paragraph be replaced by something like the following:
:In some programming languages, functions or methods can have several variants, and which variant is chosen to handle a call, depends on the call.  Languages differ in what call characteristics determine which variant a call gets dispatched to.  Multiple dispatch is when more than one characteristic affects the choice.
:A call has several characteristics.  It has some number of arguments (its arity).  Each argument counts as one characteristic, and has a value, potentially a type (static and/or a dynamic), and potentially a name.  A method call (but not a function call) has an object.  And a call potentially has an expected return type.  In single dispatch, just one of these determines dispatch.  For instance, when a single argument (the first one) determines function dispatch.  Or when method dispatch is determined by the object alone.  But when, for example, the type and/or value of two arguments affects function dispatch, that is multiple dispatch.
:There can be ambiguity.  At an implementation level, the presence of runtime dispatch code, single or multiple, is unambiguous.  But at a language level, it is less clear.  Multiple dispatch can be viewed as single dispatch on a tuple of arguments.  Some languages define arity as part of a function's name, so foo(x) and foo(x,y) are calls to different functions foo/1 and foo/2.  And the relationship between language and implementation may not be simple.  A language's compiler may, sometimes or always, be able to avoid creating runtime dispatch code.  So what looks like multiple dispatch, may be compiled into runtime single dispatch, or statically resolved.  Usually the ambiguity isn't a problem.
:Multiple dispatch is an aspect of, and sometimes refered to by the name of, multimethods, multi-methods, generic functions, function overloading, open methods, and several other things, depending on the programming language.  Dispatch (single or multiple) which uses argument type, is type polymorphism.  Using argument value is predicate dispatch.  And using return type is return type polymorphism.  Dispatch done generally at runtime is dynamic dispatch.
Comments? 98.216.110.149 (talk) 22:24, 6 July 2009 (UTC)
thread_title:  Badly broken definition 

message: This article states:
Multiple dispatch or multimethods or function overloading is the feature of some object-oriented programming languages in which a function or method can be dynamically dispatched
 
But the double dispatch article explains why that is not true http://en.wikipedia.org/wiki/Double_dispatch#Double_dispatch_is_more_than_function_overloading  —Preceding unsigned comment added by 188.108.97.59 (talk) 23:52, 16 March 2011 (UTC)
thread_title:  function overloading is not multiple dispatching 

message: Since the topic is multiple dispatch, let's remove the confusing examples for languages which do not support multiple dispatch. We could replace them with a link to Double dispatch where appropriate, or perhaps link to external articles with coding tips how to hack together mechanisms similar to multiple dispatch in languages which do not support it.
To be more specific, since C, C++ and Java do not support multiple dispatch as a built-in language mechanism, let's remove those examples. They are also examples of bad code -- we'd be hard pressed to find Java, C, or C++ guidelines recommending such approaches. (The dynamic_cast/instanceof chain of if-else branches is somewhat infamous.)
If the goal is to illustrate how multiple dispatch might work, then maybe just one example would suffice.  — Preceding unsigned comment added by 69.253.247.233 (talk) 00:37, 14 July 2011 (UTC)
replies: text: That's a bit like arguing you could do function programming in Java before is had support for lambdas, etc.  Well, yes, you could - by dint of skill, effort and a lot of conventions (contortions?).  Sort of.  (Also, a long block of 'instanceof' if statements is not multiple dispatch; it is what you have to do if you don't *have* multiple dispatch in your language (or a library/framework to emulate it). 185.55.60.122 (talk) 11:57, 16 April 2015 (UTC)
thread_title:  Let's remove the non-multiple dispatch examples. 

message: I entirely agree, I'll remove the C section. How did it get there anyway? C isn't even object-oriented, for goodness' sake.  — Preceding unsigned comment added by 79.124.84.16 (talk) 22:04, 9 November 2011 (UTC)
thread_title:  Re: Let's remove the non-multiple dispatch examples. 

message: The C example should be removed entirely. Since someone thinks it has certain educational value, I propose to add a short paragraph which:
1) says that C is not an object-oriented language and has nothing to do with multiple dispatch;
2) says that one way to emulate multiple dispatch is by means of a branch table and provide link to that article, which essentially makes the example pointless.
This is what we have now, more or less, save for the link, which I'll add shortly.  — Preceding unsigned comment added by 79.124.84.16 (talk) 19:47, 15 November 2011 (UTC)
replies: text: C (2011) has something similar to multiple dispatch, now that it has the _Generic keyword. This allows a single pseudo-function name to be called to invoked one of several actual functions, depending on the call parameter types. This is not, however, dynamic dispatch, since the target function is resolved at compile time. — Loadmaster (talk) 20:03, 18 April 2013 (UTC)

text: Interesting.  But presumably this is akin, more or less, to method overloading as in Java, where the compile-time type of the variable/pointer determines the called function? (So not really MD/MM?) 185.55.60.122 (talk) 13:54, 16 April 2015 (UTC)
thread_title:  Multiple dispatch and C 

message: The end of the Python example states:
"Functionally, this is very similar to the CLOS example, but the syntax is conventional Python."
That doesn't make any sense to me: you still use Common Lisp syntax while using CLOS. If it is making mention that CLOS is an addition to the language (which it technically isn't); then that line needs to be modified. It has nothing to do with the article at large. 2601:41:4104:ED70:D1BA:620B:FC89:F834 (talk) 05:29, 2 March 2016 (UTC)
thread_title: Python Example. CLOS related.

message: Using the implementation as provided on the prior version with calls against identifiers typed as Collideable result in a StackOverflowError (in Java 7, Java 8, & Java 12) because the type of the parameter passed in is a Collideable which binds to the interface not to the instance.  This is the same behavior as defining the interface instead as an abstract class with a concrete void collideWith(Collideable) implementation in the abstract class (for support in Java 7).  Both of these approaches are verified with calls as follows:
    Collideable a = new Asteroid();
    Collideable s = new Spaceship();
		
    a.collideWith(s);
    a.collideWith(a);
    s.collideWith(s);
    s.collideWith(a);
However, moving the implementation of the default method from the interface down into the concrete classes (of course, removing the default keyword) allows the code to work with the above calls.  If instead, the variables were typed as Asteroid a, and Spaceship s then the prior default implementation in the interface works but there's no abstraction in the identifier declarations (in the caller) - which having this abstraction in the caller is usually the desired approach.
Consequently, Java appears to do the right thing at runtime with the change to the interface.  Alas, default isn't doing what people think it will do (it doesn't actually place the default implementation into the implementing subclasses). .digamma (talk) 19:53, 19 November 2019 (UTC)
thread_title:  Java emulated implementation results in StackOverflowError