<commit_before>¿Qué entendemos por Binding?
----------------------------

El binding es la relación que se establece entre la invocación a un procedimiento-función-método y el código que se ejecuta. Otro nombre que le damos es *dispatch*. Los conceptos de binding, polimorfismo y sobrecarga son aplicables a muchos paradigmas, y tienen diferentes formas de ser entendidos en cada uno de ellos. Por el momento, este artículo se concentra fundamentalmente en el paradigma de objetos.

Dynamic method invocation
-------------------------

En objetos, cada vez que se envía un mensaje, el método invocado depende del receptor. Por ejemplo, en Smalltalk:

`figuras := {Cuadrado new. Rectangulo new. Circulo new}.`
`figuras collect: [:f | f superficie ]`

Si las clases Cuadrado, Rectangulo y Circulo tienen cada una su propia implementación de , cada vez que se envía el mensaje a la referencia el método invocado será uno distinto. Esta característica es una de las más importantes para el paradigma de objetos, ya que habilita algunas de sus herramientas más interesantes.

Tipo estático y tipo dinámico
-----------------------------

Al extender el concepto de dynamic method invocation a un lenguaje con chequeo estático de tipos, es necesario tener en cuenta la información estática que provee el sistema de tipos. En este tipo de lenguajes, a cada expresión se le asigna un tipo en forma estática. Estos tipos se ejecutan para validar la corrección de los programas antes de su ejecución y eliminar algunos posibles errores.

El valor que tome la expresión en tiempo de ejecución puede diferir del valor que es asignado a esa expresión en forma estática. Por ejemplo:

`public interface Figura {`
`    public double getSuperficie();`
`}`
`public class Circulo implements Figura {`
`    @Override`
`    public double getSuperficie() { ... }`
`    `
`    public double getRadio() { ... }`
`}`
`Figura f = new Circulo();`

Estáticamente, la variable tiene el tipo , pero cuando ese programa se ejecute, el valor de será un Circulo. La asignación `code|Figura` `f` `=` `new` `Circulo()` es válida siempre que sea un **subtipo** de . A esta regla se la conoce como **subsumption**.

La presencia de tipado estático nos obliga a analizar nuestro código desde las dos perspectivas. Al evaluar se envía el mensaje al objeto *referenciado* por la variable y por lo tanto se ejecutará el método de la clase . Sin embargo, en el momento de chequear tipos se controla que el tipo de , que es contenga el mensaje enviado.

Si intentamos evaluar se produciría un error de compilación, porque esa expresión no pasa el chequeo de tipos. Por eso, decimos que la regla de subsumption conlleva una pérdida de información de tipos. El objeto referenciado por entiende el mensaje , sin embargo el chequeador de tipos no puede verificar eso y rechaza el programa.

Sobrecarga
----------

Se dice que un *nombre de método* está **sobrecargado** en un contexto cuando es utilizado para representar dos o más métodos *distintos*, que se diferencian por su tipo o *firma*. Por ejemplo

-   Dos funciones con el mismo nombre y distinto número de parámetros o parámetros de distinto tipo.
-   Dos métodos definidos para el mismo objeto con distinto número de parámetros o parámetros de distinto tipo.

Por ejemplo el método está sobrecargado en la clase .

`class C {`
`    void m(Figura f) { println(1); }`
`    void m(Circulo c) { println(2); }`
`}`

Cuando se envía un mensaje que está sobrecargado, el sistema debe decidir cuál es el método que se debe ejecutar. En la mayoría de los lenguajes orientados a objetos, esta decisión se toma en forma estática. Por ejemplo, en la siguiente porción de código, al evaluar se ejecutará el método que recibe una figura, y no el que recibe un círculo; y por lo tanto imprimirá "1".

`Figura f = new Circulo();`
`C c = new C();`
`c.m(f); // => imprime 1!`

`C c1 := new C();`
`C c2 := new SC();`
`C sc := new SC();`

` \begin{lstlisting}[language=sool]`
` class C {`
`   function equals(other:CType) : Boolean is { writeln (1) }`
` }`

` class SC {`
`   function equals(other:CType) : Boolean is { writeln (2) }`
`   function equals(other:SCType) : Boolean is { writeln (3) }`
` }`

` CType = ObjectType { equals: CType -> Boolean }`
` SCType = ObjectType { `
`   equals: CType -> Boolean;`
`   equals: SCType -> Boolean `
` }`
` \end{lstlisting}`

\\end{frame}

\\begin{frame}\[fragile\]{Sobrecarga - Ejemplo}

` ¿Qué método se invoca en cada caso?`
` \begin{lstlisting}[language=sool]`
`   c1: CType := new C;`
`   c2: CType := new SC;`
`   sc: SCType := new SC;`

`   c1 <= equals(c1);`
`   c1 <= equals(c2);`
`   c1 <= equals(sc);`

`   c2 <= equals(c1);`
`   c2 <= equals(c2);`
`   c2 <= equals(sc);`
`   `
`   sc <= equals(c1);`
`   sc <= equals(c2);`
`   sc <= equals(sc);`
` \end{lstlisting}`

\\end{frame}

\\begin{frame}\[fragile\]{Multimethods}

` \begin{itemize}`
`   \item El método a ejecutar depende de los valores de uno o más de los parámetros del método.`
`   \item \cite{bruce2002} los presenta con una sintaxis procedural:`
`   \begin{lstlisting}[language=sool]`
` function equal(p1:Point, p2:Point): Boolean is { ... }`
` function equal(p1:ColorPoint, p2:ColorPoint): Boolean is { ... }`
`   \end{lstlisting}`
`   \item Otros lenguajes mantienen la sintaxis que destaca a uno de los parámetros como \textit{receptor}.`
`   \item Suele confundirse con la sobrecarga.`
` \end{itemize}`

\\end{frame}

\\section{Varianza} \\frame{\\tableofcontents\[sectionstyle=show/shaded,subsectionstyle=show/shaded/shaded\]}

Es algo central al paradigma de objetos, porque es lo que da pie al polimorfismo. Si se acuerdan de que cuando comenzamos con objetos diferenciamos el concepto de objeto y el de mensaje: bueno el binding es en definitiva el mecanismo que define qué método se ejecuta al enviar un mensaje. El method lookup es una de los mecanismos que llevan a cabo el binding pero no es la única.

Esencialmente, lo que nos interesa es entender en qué momento se produce ese binding, y hay básicamente dos opciones:

-   Al compilar = early binding o estático
-   Al ejecutar = late binding o dinámico

Polimorfismo de subtipos
------------------------

\\begin{frame}\[fragile\]{Polimorfismo de subtipos}

` \begin{itemize}`
`   \item Un objeto tiene muchos tipos.`
`   \item Por ejemplo las instancias de \code{ClrCellClass} tienen los tipos \code{ClrCellType} y \code{CellType}.`
`   \item \blue{Subsumption rule}: `
` \end{itemize}`
` \begin{center}`
`   $\begin{array}{c}`
`   \regla`
`     {\sequ{\Gamma}{M : S'} \quad S' <: S }`
`     {\sequ{\Gamma}{M : S}}{}`
`   \end{array}$`
` \end{center}`
` \begin{itemize}`<commit_msg>/* Sobrecarga */<commit_after>¿Qué entendemos por Binding?
----------------------------

El binding es la relación que se establece entre la invocación a un procedimiento-función-método y el código que se ejecuta. Otro nombre que le damos es *dispatch*. Los conceptos de binding, polimorfismo y sobrecarga son aplicables a muchos paradigmas, y tienen diferentes formas de ser entendidos en cada uno de ellos. Por el momento, este artículo se concentra fundamentalmente en el paradigma de objetos.

Dynamic method invocation
-------------------------

En objetos, cada vez que se envía un mensaje, el método invocado depende del receptor. Por ejemplo, en Smalltalk:

`figuras := {Cuadrado new. Rectangulo new. Circulo new}.`
`figuras collect: [:f | f superficie ]`

Si las clases Cuadrado, Rectangulo y Circulo tienen cada una su propia implementación de , cada vez que se envía el mensaje a la referencia el método invocado será uno distinto. Esta característica es una de las más importantes para el paradigma de objetos, ya que habilita algunas de sus herramientas más interesantes.

Tipo estático y tipo dinámico
-----------------------------

Al extender el concepto de dynamic method invocation a un lenguaje con chequeo estático de tipos, es necesario tener en cuenta la información estática que provee el sistema de tipos. En este tipo de lenguajes, a cada expresión se le asigna un tipo en forma estática. Estos tipos se ejecutan para validar la corrección de los programas antes de su ejecución y eliminar algunos posibles errores.

El valor que tome la expresión en tiempo de ejecución puede diferir del valor que es asignado a esa expresión en forma estática. Por ejemplo:

`public interface Figura {`
`    public double getSuperficie();`
`}`
`public class Circulo implements Figura {`
`    @Override`
`    public double getSuperficie() { ... }`
`    `
`    public double getRadio() { ... }`
`}`
`Figura f = new Circulo();`

Estáticamente, la variable tiene el tipo , pero cuando ese programa se ejecute, el valor de será un Circulo. La asignación `code|Figura` `f` `=` `new` `Circulo()` es válida siempre que sea un **subtipo** de . A esta regla se la conoce como **subsumption**.

La presencia de tipado estático nos obliga a analizar nuestro código desde las dos perspectivas. Al evaluar se envía el mensaje al objeto *referenciado* por la variable y por lo tanto se ejecutará el método de la clase . Sin embargo, en el momento de chequear tipos se controla que el tipo de , que es contenga el mensaje enviado.

Si intentamos evaluar se produciría un error de compilación, porque esa expresión no pasa el chequeo de tipos. Por eso, decimos que la regla de subsumption conlleva una pérdida de información de tipos. El objeto referenciado por entiende el mensaje , sin embargo el chequeador de tipos no puede verificar eso y rechaza el programa.

Sobrecarga
----------

Se dice que un *nombre de método* está **sobrecargado** en un contexto cuando es utilizado para representar dos o más métodos o funciones distintos, que se diferencian por su tipo. El tipo de un método incluye tanto a los tipos de los parámetros como al del valor de retorno. Por ejemplo:

-   En Haskell es posible definir funciones con el mismo nombre y distintos tipos de parámetros o distinto tipo de retorno.
-   En Java o C\# es posible definir dos métodos en la misma clase o jerarquía con distinto número de parámetros o con parámetros de distinto tipo. (La posibilidad de sobrecargar métodos variando el tipo de retorno es menos frecuente en el paradigma de objetos.)

Por ejemplo el método está sobrecargado en la clase .

`class C {`
`    void m(Figura f) { println(1); }`
`    void m(Circulo c) { println(2); }`
`}`

Cuando se envía un mensaje que está sobrecargado, el sistema debe decidir cuál es el método que se debe ejecutar. En la mayoría de los lenguajes orientados a objetos, esta decisión se toma en forma estática. (Cuando la decisión es dinámica, en lugar de sobrecarga hablamos de [\#Multimethods](-multimethods.html). Por ejemplo, en la siguiente porción de código, al evaluar se ejecutará el método que recibe una figura, y no el que recibe un círculo; y por lo tanto imprimirá "1".

`Figura f = new Circulo();`
`C c = new C();`
`c.m(f); // => imprime 1!`

La interpretación que debemos hacer es que que en realidad el mensaje enviado no se identifica únicamente por su nombre, sino que incluye los tipos de los parámetros. Desde esta perspectiva los dos métodos de la clase tienen distinto nombre, son totalmente independientes uno del otro. Debemos interpretar que el primero se denomina y el segundo . En presencia de este tipo de sobrecarga el *método a ejecutar* se decidirá en tiempo de ejecución, en función del mensaje enviado, pero el *mensaje a enviar* se decide en tiempo de compilación, a partir de la información de tipos disponible en este momento. Dado que ambos métodos tienen identificadores distintos, para invocarlos se envían mensajes distintos y la decisión entre ambos será tomada en tiempo de compilación. En resumen, el mensaje enviado a no es sino .

Polimorfismo de subtipos
------------------------

\\begin{frame}\[fragile\]{Polimorfismo de subtipos}

` \begin{itemize}`
`   \item Un objeto tiene muchos tipos.`
`   \item Por ejemplo las instancias de \code{ClrCellClass} tienen los tipos \code{ClrCellType} y \code{CellType}.`
`   \item \blue{Subsumption rule}: `
` \end{itemize}`
` \begin{center}`
`   $\begin{array}{c}`
`   \regla`
`     {\sequ{\Gamma}{M : S'} \quad S' <: S }`
`     {\sequ{\Gamma}{M : S}}{}`
`   \end{array}$`
` \end{center}`
` \begin{itemize}`
{'fraction_non_alphanumeric': 0.10085609457806767, 'fraction_numerical': 0.0028536485935589076, 'mean_word_length': 3.748741773132017, 'pattern_counts': {'":': 0, '<': 14, '<?xml version=': 0, '>': 8, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1686845', 'n_tokens_mistral': 4504, 'n_tokens_neox': 4421, 'n_words': 1714}