RE: [Python-es] Sobrecargar método

[Hernán MF]

> #- > Perdón que me desvíe un poco, pero me interesa el por qué
> #- > se quiere un modelo como este...
> #-
> #- Bueno... Sería como preguntarse para qué usar la sobrecarga
> #- de métodos en cualquier lenguaje orientado a objetos.
>
> No no no. Porque entiendo sobrecarga de métodos en static typing,
> pero a veces no es tan claro en duck typing...
>
> #- Por otra parte, no creo que sea muy común la necesidad de
> #- diseñar APIs con parámetros sean de tipos que no comparten
> #- una interfaz común y que no se pueda resolver con un par
> #- de sentencias if-isinstance.
>
> Ese es otro punto. Usar isinstance() me parece perfecto,
> ¿por qué no?

No me parece que sea otro punto.  Los que pugnan por los
multimétodos (a mí no me miren) consideran que usar
isinstance() para eso no es correcto (lleva a sorpresas),
complica la herencia (hay que saber cómo resuelve la
clase base para sobreescribir o extender) y no hace muy
legible el código (porque lo llena condiciones.)

Por ejemplo, si se implementa así:

	def foo(a, b):
		if isinstance(a, T1):
			if isinstance(b, T2):
				X
			else:
				Y
		elif isinstance(a, T3):
			if isinstance(b, T2):
				Z
			..etc..

El solo hecho de usar condiciones if-isinstance ya
impone una jerarquía sobre cuál de los parámetros y
tipos tienen preferencias unos sobre otros.  Quien testea
primero, gana.  Recuerda que python tiene herencia múltiple
y "a" puede ser tanto T1 como T3.  Aquí "a" tendría
preferencia sobre "b" y "T1" sobre "T3".

Además  ¿cómo sobreescibirías foo(a,b) para agregar una
nueva combinación de tipos (T2, T5) sin conocer el código
de la clase base?  O imagina que creas un nuevo tipo T2'
derivado de T2 y quieres especializar foo para que
ejecute (T1,T2').

Programar un mecanismo resuelva estos problemas es
implementar multimétodos.

(A mí particularmente me parece una discusión puramente
académica.)

-H.