RE: [Python-es] Sobrecargar método

[Hernán MF]

[citas reordenadas]

> A ver. ¿Por qué querés que sea un sólo método?
>
>
> Ahora, si las formas de acceder son muy distintas, ¿por qué meterlas
> en el mismo método? ¿para que desde afuera se vean con la misma API?
>
> ¿Qué pasaría si desde afuera tenés un leeDatosLista y un leeDatosArch?
>
> Por otro lado, ¿por qué decis que usar isinstance() no es aconsejable?
>
> 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.

> Ahora, si las formas de acceder son muy distintas, ¿por qué meterlas
> en el mismo método? ¿para que desde afuera se vean con la misma API?

No es una ventaja menor.  Imagina lo que sería para un programador
usar una biblioteca que fuera:

   impre.print_float(n)
   impre.print_string(s)

y así para varios tipos de parámetros.  O también:

   math.pow(3.0, 4.0)
   math.pow_floatDecimal(3.0, Decimal("4"))
   math.pow_Decimalfloat(3.0, Decimal("4"))
   math.pow_DecimalDecimal(Decimal("3"), Decimal("4"))

en vez de:

   math.pow(3.0, Decimal("4"))

(pero sin forzar la conversión previa de los parámetros
a un tipo único ;-)

> ¿La información que tenés en la lista es la misma que en el fichero?
> (por ejemplo, en ambos casos lees lineas de texto). Si es así, podés
> lograr algo como (abriendo previamente al archivo con 'file'):
>
> def leeDatos(self, datos):
> 	for linea in datos:
> 		# ...

En este caso particular esa sería la forma mas elegante.

Lo lógico sería que el/los parámetros que recibe un método cumplen
con alguna interfaz predefinida o derivan de una clase genérica
única o implementen un protocolo predeterminado.

A veces no es posible hacerlo.  El ejemplo son los
números (float, int, complex, etc.)  Los lenguajes lo resuelven
con reglas de promoción que son parte de las especificaciones.
No es tan fácil con clases definidas por el usuario.

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.

Los multimétodos son algo mas potente ya que deciden qué
método es "mejor" o "mas parecido" en caso que los tipos
de los parámetros no coincidan exactamente con lo previsto.

-H.