Envío múltiple

En la mayoría de los lenguajes de programación más populares, el código fuente se entrega y despliega en fragmentos de funcionalidad que aquí denominaremos paquetes ; la terminología específica para este concepto varía según el lenguaje. Cada paquete puede contener múltiples definiciones de tipo, valor y función; en lenguajes con un paso de compilación, los paquetes suelen compilarse por separado, y puede existir una relación de dependencia no cíclica. Un programa completo es un conjunto de paquetes, con un paquete principal que puede depender de otros paquetes, y el programa completo constituye el cierre transitivo de la relación de dependencia.

El llamado problema de la expresión se refiere a la capacidad del código de un paquete dependiente para extender comportamientos (funciones o tipos de datos) definidos en un paquete base desde dentro de un paquete incluido, sin modificar el código fuente del paquete base. Los lenguajes de programación orientada a objetos tradicionales de despacho simple hacen que sea trivial agregar nuevos tipos de datos, pero no nuevas funciones; los lenguajes funcionales tradicionales tienden a tener el efecto contrario, y el despacho múltiple, si se implementa correctamente, permite ambos. Es deseable que una implementación de despacho múltiple tenga las siguientes propiedades:

• Es posible definir diferentes "casos" de un método múltiple desde diferentes paquetes sin modificar el código fuente de un paquete base.
• La inclusión de otro paquete en el programa no debería alterar el comportamiento de una llamada a múltiples métodos determinada, siempre que dicha llamada no utilice ningún tipo de dato definido en el paquete.
• Por el contrario, si un tipo de dato se define en un paquete determinado, y una extensión multimétodo que utiliza ese tipo también se define en el mismo paquete, y un valor de ese tipo se pasa (a través de una referencia de tipo base o a una función genérica) a otro paquete sin dependencia de este, y luego se invoca el multimétodo con ese valor como argumento, se debe emplear el caso multimétodo definido en el paquete que incluye el tipo. Dicho de otro modo, dentro de un programa determinado, el mismo multimétodo invocado con el mismo conjunto de argumentos debe resolverse en la misma implementación, independientemente de la ubicación del punto de llamada y de si una definición determinada está o no "dentro del ámbito" o es "visible" en el momento de la llamada al método.

En general, es deseable que para cualquier invocación de un método múltiple, exista como máximo un candidato "óptimo" entre los casos de implementación del método múltiple, y/o que, si no lo hay, esto se resuelva de manera predecible y determinista, incluyendo el fallo. El comportamiento no determinista es indeseable. Suponiendo un conjunto de tipos con una relación de subtipo no circular, se puede definir que una implementación de un método múltiple es "mejor" (más específica) si todos los argumentos distribuidos dinámicamente en la primera son subtipos de todos los argumentos distribuidos dinámicamente especificados en la segunda, y al menos uno es un subtipo estricto. Con distribución simple y en ausencia de herencia múltiple , esta condición se satisface trivialmente, pero con distribución múltiple, es posible que dos o más candidatos satisfagan una lista de argumentos real dada, pero ninguno es más específico que el otro (un argumento dinámico es el subtipo en un caso, otro es el subtipo en el otro caso). Esto puede ocurrir particularmente si dos paquetes diferentes, que no dependen el uno del otro, extienden algún método múltiple con implementaciones relacionadas con los tipos de cada paquete, y luego un tercer paquete que incluye a ambos (posiblemente de forma indirecta) invoca el método múltiple utilizando argumentos de ambos paquetes.

Las posibles soluciones incluyen:

• Tratar cualquier llamada ambigua como un error. Esto podría detectarse en tiempo de compilación (o antes del despliegue), pero podría no detectarse hasta el tiempo de ejecución y producir un error en tiempo de ejecución.
• El orden de los argumentos, por ejemplo, se selecciona el caso con el primer argumento más específico, y los argumentos subsiguientes no se consideran para la resolución de ambigüedades a menos que el primer argumento sea insuficiente para resolver el problema.
• Construcción de otras reglas para resolver una ambigüedad en una u otra dirección. A veces, estas reglas pueden ser arbitrarias y sorprendentes. En las reglas para la resolución de sobrecarga estática en C++, por ejemplo, un tipo que coincide exactamente se considera, comprensiblemente, una mejor coincidencia que un tipo que coincide a través de una referencia de tipo base o un parámetro genérico (plantilla). Sin embargo, si las únicas coincidencias posibles son a través de un tipo base o un parámetro genérico, se prefiere el parámetro genérico sobre el tipo base, una regla que a veces produce un comportamiento inesperado.

Es bien sabido que la implementación eficiente del despacho único, incluso en lenguajes de programación que se compilan por separado a código objeto y se enlazan con un enlazador de bajo nivel (que no tiene en cuenta el lenguaje), incluso de forma dinámica al cargar o iniciar el programa o incluso bajo la dirección del código de la aplicación, es una práctica común. El método " vtable ", desarrollado en C++ y otros lenguajes de programación orientada a objetos (donde cada clase tiene un array de punteros a funciones que corresponden a las funciones virtuales de esa clase), es casi tan rápido como una llamada a un método estático, requiriendo una sobrecarga de O(1) y solo una búsqueda de memoria adicional, incluso en el caso no optimizado. Sin embargo, el método vtable utiliza el nombre de la función y no el tipo de argumento como clave de búsqueda, y no se adapta al caso de despacho múltiple. (También depende del paradigma orientado a objetos en el que los métodos son características de las clases, no entidades independientes de ningún tipo de dato en particular).

La implementación eficiente del despacho múltiple sigue siendo un problema de investigación en curso.

C# introdujo soporte para multimétodos dinámicos en la versión 4 ^{[ 8 ]} (abril de 2010) mediante la palabra clave 'dynamic'. El siguiente ejemplo muestra multimétodos. Al igual que muchos otros lenguajes de tipado estático, C# también admite la sobrecarga de métodos estáticos. ^{[ 9 ]} Microsoft espera que los desarrolladores prefieran el tipado estático al dinámico en la mayoría de los casos. ^{[ 10 ]} La palabra clave 'dynamic' admite la interoperabilidad con objetos COM y lenguajes .NET de tipado dinámico.

El siguiente ejemplo utiliza características introducidas en C# 9 y C# 10.

usando la biblioteca estática ColliderLibrary ;Console.WriteLine ( Colisión ( nuevo asteroide ( 101 ) , nueva nave espacial ( 300 ))); Console.WriteLine ( Colisión ( nuevo asteroide ( 10 ) , nueva nave espacial ( 10 ) )); Console.WriteLine ( Colisión ( nuevo asteroide ( 101 ) , nueva nave espacial ( 10 ))) ;string Collide ( SpaceObject x , SpaceObject y ) => x.Size > 100 && y.Size > 100 ? " ¡ Gran explosión!" : CollideWith ( x as dynamic , y as dynamic ) ; // Despacho dinámico al método CollideWithclase ColliderLibrary { public static string CollideWith ( Asteroide x , Asteroide y ) => "a/a" ; public static string CollideWith ( Asteroide x , Nave espacial y ) => "a/s" ; public static string CollideWith ( Nave espacial x , Asteroide y ) => "s/a" ; public static string CollideWith ( Nave espacial x , Nave espacial y ) => "s/s" ; }Registro abstracto SpaceObject ( int Size ); registro Asteroid ( int Size ) : SpaceObject ( Size ); registro Spaceship ( int Size ) : SpaceObject ( Size );

Producción:

¡Gran explosión! a/s s/s

Groovy es un lenguaje de propósito general compatible con Java e interutilizable para la JVM , que, a diferencia de Java, utiliza enlace tardío/despacho múltiple. ^{[ 11 ]}

/*  Implementación en Groovy del ejemplo de C# anterior.  El enlace tardío funciona igual al usar métodos no estáticos o compilar clases/métodos estáticamente  (anotación @CompileStatic) */ class Program { static void main ( String [] args ) { println Collider . collide ( new Asteroid ( 101 ), new Spaceship ( 300 )) println Collider . collide ( new Asteroid ( 10 ), new Spaceship ( 10 )) println Collider . collide ( new Spaceship ( 101 ), new Spaceship ( 10 )) } }clase Collider { static String collide ( SpaceObject x , SpaceObject y ) { ( x . size > 100 && y . size > 100 ) ? "big-boom" : collideWith ( x , y ) // Despacho dinámico al método collideWith }private static String colisionarCon ( Asteroide x , Asteroide y ) { "a/a" } private static String colisionarCon ( Asteroide x , Nave espacial y ) { "a/s" } private static String colisionarCon ( Nave espacial x , Asteroide y ) { "s/a" } private static String colisionarCon ( Nave espacial x , Nave espacial y ) { "s/s" } }clase SpaceObject { int size SpaceObject ( int size ) { this . size = size } }@InheritConstructors class Asteroid extends SpaceObject {} @InheritConstructors class Spaceship extends SpaceObject {}

En un lenguaje con despacho múltiple, como Common Lisp , podría verse más o menos así (ejemplo de Common Lisp mostrado):

( defclass asteroid () (( tamaño :reader tamaño :initarg :size ))) ( defclass spaceship () (( tamaño :reader tamaño :initarg :size ))) ( defun space-object ( clase tamaño ) ( make-instance clase :size tamaño )); colisionar-con es una función genérica con despacho múltiple ( defmethod colisionar-con (( asteroide x ) ( asteroide y )) "a/a" ) ( defmethod colisionar-con (( asteroide x ) ( nave espacial y )) "a/s" ) ( defmethod colisionar-con (( nave espacial x ) ( asteroide y )) "s/a" ) ( defmethod colisionar-con (( nave espacial x ) ( nave espacial y )) "s/s" )( defun colisionar ( x y ) ( si ( y ( > ( tamaño x ) 100 ) ( > ( tamaño y ) 100 )) "gran explosión" ( colisionar con x y )))( print ( colisionar ( objeto espacial 'asteroide 101 ) ( objeto espacial 'nave espacial 300 ))) ( print ( colisionar ( objeto espacial 'asteroide 10 ) ( objeto espacial 'nave espacial 10 ))) ( print ( colisionar ( objeto espacial 'nave espacial 101 ) ( objeto espacial 'nave espacial 10 )))

Lo mismo ocurre con los demás métodos. No se utilizan pruebas explícitas ni la conversión dinámica de tipos.

Ante la presencia de despacho múltiple, la idea tradicional de que los métodos se definen en clases y se contienen en objetos resulta menos atractiva: cada método que colisiona con los anteriores se asocia a dos clases diferentes, no a una. Por lo tanto, la sintaxis especial para la invocación de métodos generalmente desaparece, de modo que la invocación de métodos se ve exactamente igual que la invocación de funciones ordinarias, y los métodos se agrupan no en clases, sino en funciones genéricas .

Julia tiene despacho múltiple incorporado, y es fundamental para el diseño del lenguaje. ^{[ 3 ]} La versión en Julia del ejemplo anterior podría verse así:

tipo abstracto SpaceObject finstruct Asteroide <: SpaceObject tamaño :: Int fin struct Nave espacial <: SpaceObject tamaño :: Int fincolisionar_con ( :: Asteroide , :: Nave espacial ) = "a/s" colisionar_con ( :: Nave espacial , :: Asteroide ) = "s/a" colisionar_con ( :: Nave espacial , :: Nave espacial ) = "s/s" colisionar_con ( :: Asteroide , :: Asteroide ) = "a/a"colisionar ( x :: SpaceObject , y :: SpaceObject ) = ( x . size > 100 && y . size > 100 ) ? "¡Gran explosión!" : colisionar_con ( x , y )

Producción:

julia> colisionar ( Asteroide ( 101 ), Nave espacial ( 300 )) "¡Gran explosión!"julia> colisionar ( Asteroide ( 10 ), Nave espacial ( 10 )) "a/s"julia> colisionar ( Nave espacial ( 101 ), Nave espacial ( 10 )) "s/s"

Raku , al igual que Perl, utiliza ideas probadas de otros lenguajes, y los sistemas de tipos han demostrado ofrecer ventajas convincentes en el análisis de código del lado del compilador y una semántica potente del lado del usuario mediante el despacho múltiple.

Posee tanto multimétodos como multisubrutinas. Dado que la mayoría de los operadores son subrutinas, también cuenta con múltiples operadores despachados.

Además de las restricciones de tipo habituales, también cuenta con restricciones de ubicación que permiten crear subrutinas muy especializadas.

subconjunto Masa de Real donde 0 ^..^ Inf ; rol Objeto-estelar { tiene Masa $.mass es requerido ; nombre del método () devuelve Str {...}; } clase Asteroide hace Stellar-Object { nombre del método () { 'un asteroide' } } class Spaceship does Stellar-Object { has Str $.name = 'some unnamed spaceship' ; } mi Str @destroyed = < obliterado destruido destrozado >; mi Str @damaged = « dañado 'colisionó con' 'fue dañado por' »; # Agregamos múltiples candidatos a los operadores de comparación numérica porque los estamos comparando numéricamente, # pero no tiene sentido que los objetos se conviertan a un tipo Numérico. # (Si se convirtieran, no necesariamente necesitaríamos agregar estos operadores). # También podríamos haber definido operadores completamente nuevos de esta misma manera. multi sub infix: « <=> » ( Stellar-Object:D $a , Stellar-Object:D $b ) { $a . mass <=> $b . mass } multi sub infix: « < » ( Stellar-Object:D $a , Stellar-Object:D $b ) { $a . mass < $b . mass } multi sub infix: « > » ( Stellar-Object:D $a , Stellar-Object:D $b ) { $a . mass > $b . masa } multi sub infijo: « == » ( Stellar-Object:D $a , Stellar-Object:D $b ) { $a . masa == $b . masa } # Define un nuevo despachador múltiple y agrega algunas restricciones de tipo a los parámetros. # Si no lo hubiéramos definido, habríamos obtenido uno genérico sin restricciones. proto sub collide ( Stellar-Object:D $, Stellar-Object:D $ ) {*} # No es necesario repetir los tipos aquí ya que son los mismos que el prototipo. # La restricción 'where' técnicamente solo se aplica a $b, no a toda la firma. # Tenga en cuenta que la restricción 'where' utiliza el candidato a operador `<` que agregamos anteriormente. multi sub collide ( $a , $b where $a < $b ) { say "$a.name() fue @destroyed.pick() por $b.name()" ; } multi sub collide ( $a , $b where $a > $b ) { # redistribuir al candidato anterior con los argumentos intercambiados samewith $b , $a ; } # Esto tiene que ir después de los dos primeros porque los otros # tienen restricciones 'where', que se comprueban en el # orden en que se escribieron las subrutinas. (Esta siempre coincidiría.) multi sub collide ( $a , $b ) { # aleatorizar el orden my ( $n1 , $n2 ) = ( $a . name , $b . name ). pick (*); say "$n1 @damaged.pick() $n2" ; } # Los siguientes dos candidatos pueden estar en cualquier lugar después del proto, # porque tienen tipos más especializados que los tres anteriores.# Si las naves tienen masas desiguales, se llama a uno de los dos primeros candidatos. multi sub collide ( Spaceship $a , Spaceship $b where $a == $b ){ my ( $n1 , $n2 ) = ( $a . name , $b . name ). pick (*); say "$n1 colisionó con $n2, y ambas naves fueron " , ( @destroyed . pick , 'dejó dañado' ). pick ; } # Puedes desempaquetar los atributos en variables dentro de la firma. # Incluso podrías tener una restricción sobre ellos `(:mass($a) donde 10)`. multi sub collide ( Asteroide $ (: masa ( $a )), Asteroide $ (: masa ( $b )) ){ decir "dos asteroides colisionaron y se combinaron en un asteroide más grande de masa { $a + $b }" ; } mi nave espacial $Enterprise .= new (: masa ( 1 ),: nombre ( 'La Enterprise' )); colisionar asteroide . new (: masa ( .1 )), $Enterprise ; colisionar $Enterprise , nave espacial . new (: masa ( .1 )); colisionar $Enterprise , asteroide . new (: masa ( 1 )); colisionar $Enterprise , nave espacial . new (: masa ( 1 )); colisionar asteroide . new (: masa ( 10 )), asteroide . new (: masa ( 5 )); 

En lenguajes que no admiten despacho múltiple a nivel de definición o sintaxis, a menudo es posible agregarlo mediante una extensión de biblioteca . JavaScript y TypeScript no admiten multimétodos a nivel sintáctico, pero es posible agregar despacho múltiple a través de una biblioteca. Por ejemplo, el paquete multimethod ^{[ 12 ]} proporciona una implementación de despacho múltiple y funciones genéricas.

Versión con tipado dinámico en JavaScript:

import { multi , method } from '@arrows/multimethod'clase Asteroide {} clase Nave espacial {}const colisionarCon = multi ( método ([ Asteroide , Asteroide ], ( x , y ) => { // lidiar con el asteroide que golpea al asteroide }), método ([ Asteroide , Nave espacial ], ( x , y ) => { // lidiar con el asteroide que golpea a la nave espacial }), método ([ Nave espacial , Asteroide ], ( x , y ) => { // lidiar con la nave espacial que golpea al asteroide }), método ([ Nave espacial , Nave espacial ], ( x , y ) => { // lidiar con la nave espacial que golpea a la nave espacial }), )

Versión con tipado estático en TypeScript:

import { multi , method , Multi } from '@arrows/multimethod'clase Asteroide {} clase Nave espacial {}tipo CollideWith = Multi & { ( x : Asteroide , y : Asteroide ) : void ( x : Asteroide , y : Nave espacial ) : void ( x : Nave espacial , y : Asteroide ) : void ( x : Nave espacial , y : Nave espacial ) : void }const colideWith : CollideWith = multi ( method ([ Asteroid , Asteroid ], ( x , y ) => { // lidiar con el asteroide que golpea al asteroide }), method ([ Asteroid , Spaceship ], ( x , y ) => { // lidiar con el asteroide que golpea a la nave espacial }), method ([ Spaceship , Asteroid ], ( x , y ) => { // lidiar con la nave espacial que golpea al asteroide }), method ([ Spaceship , Spaceship ], ( x , y ) => { // lidiar con la nave espacial que golpea a la nave espacial }), )

Se puede agregar despacho múltiple a Python usando una extensión de biblioteca . Por ejemplo, usando el módulo multimethod.py ^{[ 13 ]} y también con el módulo multimethods.py ^{[ 14 ]} que proporciona multimétodos al estilo CLOS para Python sin cambiar la sintaxis subyacente ni las palabras clave del lenguaje.

from typing import Anyimport game_behaviors from game_objects import Asteroid , Spaceship from multimethods import Dispatchcolisionar : Dispatch = Dispatch ( ) colisionar.add_rule ( ( Asteroid , Spaceship ) , game_behaviors.as_func ) colisionar.add_rule ( ( Spaceship , Spaceship ) , game_behaviors.ss_func ) colisionar.add_rule ( ( Spaceship , Asteroid ) , game_behaviors.sa_func )​​​​​def aa_func ( a : Any , b : Any ) -> None : """Comportamiento cuando un asteroide choca con otro asteroide.""" # ...define un nuevo comportamiento...colisionar . add_rule (( Asteroide , Asteroide ), aa_func )

# ...más tarde... colisionar ( cosa1 , cosa2 )

Funcionalmente, es muy similar al ejemplo de CLOS, pero la sintaxis es la convencional de Python.

Utilizando decoradores (introducidos desde Python 2.4), Guido van Rossum produjo una implementación de ejemplo de multimétodos ^{[ 15 ]} con una sintaxis simplificada:

@multimethod ( Asteroide , Asteroide ) def colisionar ( a : Asteroide , b : Asteroide ) -> Ninguno : """Comportamiento cuando un asteroide choca con otro asteroide.""" # ...definir nuevo comportamiento...@multimethod ( Asteroide , Nave espacial ) def colisionar ( a : Asteroide , b : Nave espacial ) -> Ninguno : """Comportamiento cuando un asteroide choca con una nave espacial.""" # ...definir nuevo comportamiento...# ... definir otras reglas multimétodo ...

y luego procede a definir el decorador multimétodo.

El paquete PEAK-Rules proporciona despacho múltiple con una sintaxis similar al ejemplo anterior. ^{[ 16 ]} Posteriormente fue reemplazado por PyProtocols. ^{[ 17 ]}

La biblioteca Reg también admite despacho múltiple y por predicado. ^{[ 18 ]}

Con la introducción de sugerencias de tipo , es posible el despacho múltiple con una sintaxis aún más simple. Por ejemplo, usando plum-dispatch ,

desde envío de importación de ciruelas@dispatch def collide ( a : Asteroide , b : Asteroide ) -> None : """Comportamiento cuando un asteroide choca con otro asteroide.""" # ...define un nuevo comportamiento...@dispatch def collide ( a : Asteroide , b : Nave espacial ) -> None : """Comportamiento cuando un asteroide choca con una nave espacial.""" # ...define nuevo comportamiento...# ...definir reglas adicionales...

C no tiene despacho dinámico, por lo que debe implementarse manualmente de alguna forma. A menudo se utiliza una enumeración para identificar el subtipo de un objeto. El despacho dinámico se puede realizar buscando este valor en una tabla de ramificación de punteros a funciones . Aquí hay un ejemplo sencillo en C:

typedef void ( * CollisionCase )( void );void collisionAsteroidAsteroid ( void ) { // manejar la colisión asteroide-asteroide... }void collisionAsteroidSpaceship ( void ) { // manejar la colisión asteroide-nave espacial... }void collisionSpaceshipAsteroid ( void ) { // manejar la colisión entre la nave espacial y el asteroide... }void collisionSpaceshipSpaceship ( void ) { // manejar la colisión entre naves espaciales... }typedef enum { COLLIDEABLE_ASTEROID = 0 , COLLIDEABLE_SPACESHIP , COLLIDEABLE_COUNT // no es un tipo de Collideable en sí mismo, sino que se utiliza para encontrar el número de objetos espaciales definidos } Collideable ;CollisionCase collisionCases [ COLLIDEABLE_COUNT ][ COLLIDEABLE_COUNT ] = { { & collisionAsteroidAsteroid , & collisionAsteroidSpaceship }, { & collisionSpaceshipAsteroid , & collisionSpaceshipSpaceship } };void colisionar ( Collideable a , Collideable b ) { ( * colisionCases [ a ][ b ])(); }int main ( void ) { collide ( COLLIDEABLE_SPACESHIP , COLLIDEABLE_ASTEROID ); }

Con la biblioteca C Object System, ^{[ 19 ]} C admite el despacho dinámico similar a CLOS. Es totalmente extensible y no requiere ningún manejo manual de los métodos. Los mensajes dinámicos (métodos) son despachados por el despachador de COS, que es más rápido que Objective-C . Aquí hay un ejemplo en COS:

#include <stdio.h> #include <cos/Object.h> #include <cos/gen/object.h>// clasesdefclass ( Asteroide ) // miembros de datos endclassdefclass ( Spaceship ) // miembros de datos endclass// genéricosdefgeneric ( bool , colisionar_con , _1 , _2 );// multimétodosdefmethod ( bool , collide_with , Asteroid , Asteroid ) // manejar el impacto del asteroide endmethoddefmethod ( bool , collide_with , Asteroid , Spaceship ) // Gestionar el impacto del asteroide contra la nave espacial endmethoddefmethod ( bool , collide_with , Spaceship , Asteroid ) // Gestionar el choque de la nave espacial con el asteroide endmethoddefmethod ( bool , collide_with , Spaceship , Spaceship ) // maneja el choque de naves espaciales endmethod// ejemplo de usoint main ( void ) { OBJ a = gnew ( Asteroide ); OBJ s = gnew ( Nave espacial );printf ( "<a,a> = %d \n " , collide_with ( a , a )); printf ( "<a,s> = %d \n " , collide_with ( a , s )); printf ( "<s,a> = %d \n " , collide_with ( s , a )); printf ( "<s,s> = %d \n " , collide_with ( s , s ));grelease ( a ); grelease ( s ); }

A partir de 2021C ++ admite de forma nativa solo despacho único, aunque Bjarne Stroustrup (y colaboradores) propusieron en 2007 agregar múltiples métodos (despacho múltiple). ^{[ 20 ]} Los métodos para sortear este límite son análogos: usar el patrón Visitor , la conversión dinámica o una biblioteca:

// Ejemplo que utiliza la comparación de tipos en tiempo de ejecución mediante dynamic_castclase Colisionable { público : virtual void colisionarCon ( Colisionable & otro ) = 0 ; };clase Asteroide : public Colisionable { public : void colisionarCon ( Colisionable & otro ) { // dynamic_cast a un tipo puntero devuelve nullptr si la conversión falla // (dynamic_cast a un tipo de referencia lanzaría una excepción en caso de fallo) if ( Asteroide * asteroide = dynamic_cast < Asteroide *> ( & otro )) { // manejar la colisión Asteroide-Asteroide } else if ( Nave espacial * nave espacial = dynamic_cast < Nave espacial *> ( & otro )) { // manejar la colisión Asteroide-Nave espacial } else { // manejo de colisión predeterminado aquí } } };clase Spaceship : public Collideable { public : void collideWith ( Collideable & other ) { if ( Asteroid * asteroid = dynamic_cast < Asteroid *> ( & other )) { // manejar la colisión Spaceship-Asteroid } else if ( Spaceship * spaceship = dynamic_cast < Spaceship *> ( & other )) { // manejar la colisión Spaceship-Spaceship } else { // manejo de colisión predeterminado aquí } } };

o tabla de búsqueda de puntero a método :

importar std ;usando std :: unordered_map ;clase Collideable { protected : explicit Collideable ( uint32_t cid ) : tid { cid } {}virtual ~ Collideable () = predeterminado ;const uint32_t tid ; // tipo id;using CollisionHandler = void ( Collideable ::* )( Collideable & other ); using CollisionHandlers = unordered_map < uint64_t , CollisionHandler > ;static void addHandler ( uint32_t id1 , uint32_t id2 , CollisionHandler handler ) { collisionCases.insert ( CollisionHandlers :: value_type ( key ( id1 , id2 ) , handler )) ; }static uint64_t key ( uint32_t id1 , uint32_t id2 ) { return uint64_t ( id1 ) << 32 | id2 ; }static inline CollisionHandlers collisionCases {}; public : void collideWith ( Collideable & other ) { if ( auto handler = collisionCases . find ( key ( tid , other . tid )); handler != collisionCases . end ()) { ( this ->* handler -> second )( other ); // puntero a llamada de método } else { // manejo de colisiones predeterminado } } };clase Asteroide : público Colisionable { privado : void asteroidCollision ( Colisionable & otro ) { // manejar colisión asteroide-asteroide }void spaceshipCollision ( Collideable & other ) { // manejar la colisión asteroide-nave espacial } public : Asteroid () : Collideable ( cid ) {}~ Asteroide () = predeterminado ;static void initCases (); static inline const uint32_t cid = typeid ( Asteroid ) .hash_code (); };clase Spaceship : public Collideable { private : void asteroidCollision ( Collideable & other ) { // manejar la colisión entre la nave espacial y el asteroide }void spaceshipCollision ( Collideable & other ) { // manejar la colisión entre naves espaciales } public : Spaceship () : Collideable ( cid ) {}~ Nave espacial () = predeterminado ;static void initCases (); static inline const uint32_t cid = typeid ( Spaceship ). hash_code (); // class id };void Asteroid::initCases () { addHandler ( cid , cid , CollisionHandler ( & Asteroid :: asteroidCollision )); addHandler ( cid , Spaceship :: cid , CollisionHandler ( & Asteroid :: spaceshipCollision )); }void Spaceship::initCases () { addHandler ( cid , Asteroid :: cid , CollisionHandler ( & Spaceship :: asteroidCollision )); addHandler ( cid , cid , CollisionHandler ( & Spaceship :: spaceshipCollision )); }int main ( int argc , char * argv []) { Asteroide :: initCases (); Nave espacial :: initCases ();Asteroide a1 ; Asteroide a2 ; Nave espacial s1 ; Nave espacial s2 ;a1.collideWith ( a2 ) ; a1.collideWith ( s1 ) ;​​s1.collideWith ( s2 ) ; s1.collideWith ( a1 ) ; }​​

La biblioteca YOMM2 ^{[ 21 ]} proporciona una implementación rápida y ortogonal de multimétodos abiertos.

La sintaxis para declarar métodos abiertos se inspira en una propuesta para una implementación nativa en C++. La biblioteca requiere que el usuario registre todas las clases utilizadas como argumentos virtuales (y sus subclases), pero no requiere ninguna modificación al código existente. Los métodos se implementan como funciones C++ inline ordinarias; se pueden sobrecargar y pasar por puntero. No hay límite en el número de argumentos virtuales, y estos se pueden combinar arbitrariamente con argumentos no virtuales.

La biblioteca utiliza una combinación de técnicas (tablas de despacho comprimidas, tabla hash de enteros sin colisiones ) para implementar llamadas a métodos en tiempo constante, a la vez que minimiza el uso de memoria. Despachar una llamada a un método abierto con un único argumento virtual requiere solo entre un 15 % y un 30 % más de tiempo que llamar a una función miembro virtual ordinaria, cuando se utiliza un compilador optimizador moderno.

El ejemplo de los asteroides se puede implementar de la siguiente manera:

#incluir <yorel/yomm2/keywords.hpp>importar std ;usando std :: unique_ptr ;clase Colisionable { público : virtual ~ Colisionable () = predeterminado ; };clase Asteroide : público Colisionable { // ... };clase Nave espacial : público Colisionable { // ... };registrar_clases ( Colisionable , Nave espacial , Asteroide );declare_method ( void , collideWith , ( virtual_ < Collideable &> , virtual_ < Collideable &> ));define_method ( void , collideWith , ( Collideable & left , Collideable & right )) { // manejo de colisiones predeterminado }define_method ( void , collideWith , ( Asteroid & left , Asteroid & right )) { // manejar la colisión asteroide-asteroide }define_method ( void , collideWith , ( Asteroid & left , Spaceship & right )) { // manejar la colisión asteroide-nave espacial }define_method ( void , collideWith , ( Spaceship & left , Asteroid & right )) { // manejar la colisión entre la nave espacial y el asteroide }define_method ( void , collideWith , ( Spaceship & left , Spaceship & right )) { // manejar la colisión entre naves espaciales }int main ( int argc , char * argv []) { yorel :: yomm2 :: update_methods ();unique_ptr < Collideable > a1 ( std :: make_unique < Asteroid > ()); unique_ptr < Collideable > a2 ( std :: make_unique < Asteroid > ()); unique_ptr < Collideable > s1 ( std :: make_unique < Spaceship > ()); unique_ptr < Collideable > s2 ( std :: make_unique < Spaceship > ()); // nota: tipos parcialmente borradoscolisionarCon ( * a1 , * a2 ); // Colisión asteroide-asteroide colisionarCon ( * a1 , * s1 ); // Colisión asteroide-nave espacial colisionarCon ( * s1 , * a1 ); // Colisión nave espacial-asteroide colisionarCon ( * s1 , * s2 ); // Colisión nave espacial-nave espacialdevolver 0 ; }

Stroustrup menciona en *The Design and Evolution of C++* que le gustaba el concepto de multimétodos y consideró implementarlo en C++, pero afirma no haber podido encontrar una implementación de ejemplo eficiente (comparable a las funciones virtuales) ni resolver algunos posibles problemas de ambigüedad de tipos. Luego afirma que, si bien la característica seguiría siendo útil, se puede implementar aproximadamente utilizando despacho doble o una tabla de búsqueda basada en tipos, como se describe en el ejemplo de C/C++ anterior, por lo que es una característica de baja prioridad para futuras revisiones del lenguaje. ^{[ 22 ]}

A partir de 2021Al igual que muchos otros lenguajes de programación orientados a objetos, D admite de forma nativa solo despacho único. Sin embargo, es posible emular métodos múltiples abiertos como una función de biblioteca en D. La biblioteca openmethods ^{[ 23 ]} es un ejemplo.

// Declaración Matrix plus ( virtual ! Matrix , virtual ! Matrix );// Sobreescritura para dos objetos DenseMatrix @method Matrix _plus ( DenseMatrix a , DenseMatrix b ) { const int nr = a . rows ; const int nc = a . cols ; assert ( a . nr == b . nr ); assert ( a . nc == b . nc ); auto result = new DenseMatrix ; result . nr = nr ; result . nc = nc ; result . elems . length = a . elems . length ; result . elems [] = a . elems [] + b . elems []; return result ; }// Sobreescritura para dos objetos DiagonalMatrix @method Matrix _plus ( DiagonalMatrix a , DiagonalMatrix b ) { assert ( a . rows == b . rows ); double [] sum ; sum . length = a . elems . length ; sum [] = a . elems [] + b . elems []; return new DiagonalMatrix ( sum ); }

En un lenguaje con despacho único, como Java , el despacho múltiple se puede emular con múltiples niveles de despacho único:

interface Collideable { void collideWith ( Collideable other );// Estos métodos necesitarían nombres diferentes en un lenguaje sin sobrecarga de métodos. void collideWith ( Asteroide asteroide ); void collideWith ( Nave espacial nave espacial ); }class Asteroid implements Collideable { public void collideWith ( Collideable other ) { // Llama a collideWith en el otro objeto. other . collideWith ( this ); }public void collideWith ( Asteroide asteroide ) { // Manejar la colisión asteroide-asteroide. }public void collideWith ( Spaceship spaceship ) { // Manejar la colisión asteroide-nave espacial. } }class Spaceship implements Collideable { public void collideWith ( Collideable other ) { // Llama a collideWith en el otro objeto. other . collideWith ( this ); }public void collideWith ( Asteroide asteroide ) { // Manejar la colisión entre la nave espacial y el asteroide. }public void collideWith ( Spaceship spaceship ) { // Manejar la colisión entre naves espaciales. } }

instanceofTambién se pueden utilizar comprobaciones en tiempo de ejecución en uno o ambos niveles.