Habiendo ido el sabado a la tarde a la PyCon, escuche al tipejo de Google quejarse de el excesivo envio de mensajes entre objetos.

Recien estuve chusmeando un poco, y me entero de que casi todos los lenguajes OO, cuando creas un objeto A que hereda de B, la maquina virtual crea un objeto A, un objeto B, y los relaciona.

¿Porque?

¿No es mas comodo y eficiente, crear un objeto A con las caracteristicas de B?

osea, que en el codigo fuente, A herede de B, pero cuando todo se convierta a bytecode, estos "dos objetos" se conviertan en uno solo...

Probablemente no me se explicar la idea... pero bue, ustedes entenderan :P.

se que hay una razon para eso, no recuerdo bien, pero creo que servia a la hora de instanciar clases, o algo asi. leatex que labura(y vive) en smalltalk quizas nos pueda iluminar.

jajaja, me causó gracia eso de que vivo en smalltalk.
entiéndanme, para nosotros smalltalk es a los lenguajes de programación, lo que linux es a los sistemas operativos. es lo mejor, pero nadie lo usa porque no lo conocen.

en fin, no entendí muy bien el planteo de tese. a lo mejor si puede expresar mejor la idea se me ocurre algo más.
incluso reenvié el post a una lista de smalltakeros, esos que son fanáticos en serio, y obtuve respuestas como "no se entiende lo que plantea" o "un objeto no hereda de otro, sino las clases" (aunque una clase es un objeto).

seguramente tiene que ver con la forma en que realiza la búsqueda de los métodos, cuando uno envía un mensaje. en smalltalk existe un algoritmo de "method lookup" que va muy de la mano con lo que se denomina el metamodelo de smalltalk. es como el problema del huevo y la gallina, porque toda clase es un objeto, pero a su vez todo objeto es instancia de una clase; las clases son instancias de Metaclase, pero a su vez Metaclase es una clase, o sea que es un objeto, o sea que es instancia de otra clase, y así...
entonces cómo se busca en método en todo ese enredo de clases es complejo, pero efectivo.
además, ¿qué pasaría cuando se redefine un método? si dos clases implementan un mismo método, y una hereda de la otra, ¿qué implementación se usaría? ¿cómo se resolverían las llamadas a super?

Ok... aver si me explico mejor (y probablemente este equivocado):

Tengo la clase Transporte. Entiende el mensaje "movete: aca" , donde "aca" es un par ordenado.

Tengo la clase Auto, que hereda de transporte. Entiende otros mensajes que no vienen al caso (como por ejemplo, "explota").


Creo una instancia de la clase Auto (llamemosla esteAuto).
La VM, crea:
A) Una instancia de la clase Auto.
B) Una instancia de la clase Transporte.
(C - crea una clase de bla. bla. bla... hasta llegar a Object).

hago:

esteAuto movete:(4,5)

El motor:
Envia el mensaje a Transporte,
Transporte envia el mensaje a Auto.
Auto procesa la respuesta (si la hay).
Auto responde a Transporte.
Transporte responde a Auto.
Auto responde al programa

(envia 6 mensajes).

(no se si en Smalltalk es asi, pero recuerdo de en la cursada haber tenido que escribir varias veces metodos que solo dicen "super movete:aca")

¿No seria mas eficiente (a nivel velocidad, no a nivel memoria) que Transporte tenga dentro de si mismo, el codigo de todos los mensajes que hereda?

Entonces el motor:
Envia el mensaje a Auto,
Auto procesa.
Transporte responde al programa.

Enviando solo 3 mensajes (asumiendo que no hay mas clases involucradas).

En el caso de herencias de multiples niveles (supongamos que Transporte hereda de Object, y Object acepta el mensaje... nose... "Dispose"), se estaria enviando siempre 3 mensajes.

¿Esto es asi (tambien en smalltalk? en realidad, yo hablaba de algo onda java) ? ¿O la estoy errando feo?

mmm... a ver...
creo que entre tanto lío te confundiste vos mismo con algo, o yo de nuevo no te entendí muy bien.

Teseracto escribió:esteAuto movete4,5)

El motor:
10 Envia el mensaje a Transporte,
20 Transporte envia el mensaje a Auto.
30 Auto procesa la respuesta (si la hay).
40 Auto responde a Transporte.
50 Transporte responde a Auto.
60 Auto responde al programa

¿por qué le motor envía el mensaje a transporte? el mensaje se envía a la instancia de Auto, o sea que el motor va a buscar ahí. si no la encuentra la va a buscar en la superclase.
no entiendo por ejemplo ese doble envío de mensajes en las líneas 40 y 50.

Teseracto escribió:(no se si en Smalltalk es asi, pero recuerdo de en la cursada haber tenido que escribir varias veces metodos que solo dicen "super movete:aca")

un método que sólo envía a super tiene una única función: pérdida de eficiencia. no tiene ningún sentido tener un método que solamente "forwardea" un mensaje a su superclase.

Teseracto escribió:¿No seria mas eficiente (a nivel velocidad, no a nivel memoria) que Transporte tenga dentro de si mismo, el codigo de todos los mensajes que hereda?

acá es donde creo que te mareaste. Transporte no hereda nada, es la superclase.

Teseracto escribió:Entonces el motor:
Envia el mensaje a Auto,
Auto procesa.
Transporte responde al programa.

Transporte no responde nada, no está interviniendo en mi programa. Mi programa tiene instancias de Auto, que es subclase de Transporte. Para lo único que sirve es para "guardar" la implementación del método, pero el que dirige la batuta es Auto.

igual, como dije, no sé si te entendí muy bien. igual por lo que estoy viendo cada virtual machine de cada lenguaje debe funcionar diferente.
en smalltalk cada clase tiene un method dictionary (una tablita) donde guarda las implementaciones de los métodos. la ejecución de tu ejemplo sería algo así:

la instancia esteAuto recibe el mensaje #movete:
el "motor" (¿qué sería el motor?) ejecuta el method lookup
- busca la clase de la cual es instancia esteAuto
- revisa en el method dictionary de Auto si existe una implementación para #movete:
- si no la encuentra busca la superclase de Auto
- revisa en el method dictionary de Transporte si existe una implementación para #movete:
- la encuentra y le retorna la implementación del método a esteAuto
esteAuto "ejecuta" #movete: usando como colaborador (4,5) y devuelve el resultado

Si... me marie mal XD.

el texto corregido seria:

El programa envia el mensaje a Auto,
Auto envia el mensaje a Transporte.
Transporte procesa la respuesta (si la hay).
Transporte responde a Auto.
Auto responde al programa

y la segunda parte:
Envia el mensaje a Auto,
Auto procesa.
Auto responde al programa.


Tengo que pensar las cosas y escribir despues :P.


Esta duda surgio, revisando apuntes de C#, en donde el profe dijo que, cada vez que instanciabas un objeto, se creaba una instancia de dicho objeto, y otra instancia por cada superclase.

Cita:un método que sólo envía a super tiene una única función: pérdida de eficiencia. no tiene ningún sentido tener un método que solamente "forwardea" un mensaje a su superclase.

Excelente, con razon no soy ayudante :P


Bueno... espero con esto haber aclarado todas las dudas sobre lo que quise decir, y no dije :P

bueno tese, ya te entendi(mos). se armó alto debate en el foro de club smalltak. no voy a poner todo acá, pero seguro podés entrar a ver las respuestas vos: http://groups.google.com.ar/group/clubs ... 95915b618d
creo que no hace falta que te registres para poder leer.
muchas respuestas son enfocadas desde el lado smalltalk, obvio, pero bueno, seguro te sirve para despejar un poco más tus dudas.

otro "problema" que podría surgir de implementar las instancias como sugerís, es el tema de las variables. las instancias de Auto también tienen como variables las definidas en Transporte, y ahí viene todo un bardo con la ubicación de la memoria y demás.
por ahí es más fácil resolver este dilema en los lenguajes tipados, porque todo se compila y ya está listo para usar. si hacés algún cambio tenés que recompilar y arranca de nuevo.

pero en smalltalk es muy diferente, porque es un lenguaje "vivo", donde el concepto de "tiempo de ejecución" casi no existe. vos podés cambiar la forma de una clase (editar, agregar o sacar métodos o variables) y sus instancias cambian automáticamente. o sea que si vos agregás una variable nueva en Transporte, automáticamente las instancias de Auto tendrían esa variable.
existen implementaciones que mantienen historia, es decir, cada instancia mantiene la forma de la clase con que se creó, y cualquier cambio en una clase o superclase solamente se ve reflejado en las nuevas instancias.

en fin, es una pregunta bastante "filosófica" la tuya.

Como dice leatex, creo que separar el padre del hijo aporta al dinamismo: si quiero agregar un método al padre, lo agrego y no tengo que estar tocando a cada hijo. Después, si le pido algo al hijo, si el hijo no tiene el método se le pregunta al padre y listo.

En realidad, me da la sensación que separar el padre del hijo como dos instancias distintas es como si la Herencia se convirtiera en una relación de Delegación. Miren este caso:

Instancio un Auto:

La VM instancia un Auto.
La VM instancia un Transporte.
La VM agrega una variable "<padre>" al Auto, que apuntará a la instancia de Transporte.

Entonces, cuando yo le pido "movete" al Auto, ocurre lo siguiente:

Busco el método en Auto.
Si está, lo ejecuto.
Si no está, ejecuto "<padre> movete".

Y así recursivamente hasta que encuentre el método, o no lo encuentre y diga que no lo entiende.
Capaz esto demuestra que a nivel implementación, la delegación siempre resulta más ventajosa que la replicación de código (aunque sea de padre a hijo y en "tiempo de ejecución"). Muchas veces se prefiere "componer" un objeto con otros, que permite variar la composición del objeto durante la ejecución mucho más fácilmente y de modo purista, que heredar de un padre que es fijo o debería serlo (cambiar la herencia seguro que en smalltalk se puede pero ya roza lo bizarro), y que me impone un comportamiento "de por vida". Por eso, uno de los postulados de Gamma y cía. siempre fue:

"Object Composition over Inheritance".

En principio, a veces la herencia está vista como que rompe el paradigma (creo que ni siquiera forma parte del modelo original de POO), ya que no cumple con un verdadero encapsulamiento, porque uno muchas veces está obligado a conocer la implementación de la clase padre (por ejemplo, al heredarse variables de instancia).

Ahora, en Java es así? Porque no se pueden instanciar clases abstractas por ejemplo, en ese caso que haría? O la VM usa justamente sus poderes de VM para inventar algo e instanciarla igual?

Quedan muchas dudas... de todas formas, seguramente haya una explicación mucho más convincente y clara .

claro, como dice pablo, la VM se encarga de todo.
esa variable "padre" que menciona no es más que el famoso "super" que existe en smalltalk, creo que en java, y no sé en el resto. o sea "viene de fábrica". por eso un método que solamente haga "super movete" no tiene sentido porque eso es lo que hace la VM.

dejo otra aclaración que me hicieron en el grupo de smalltalk:

Cita:podemos decir que en los lenguajes donde "no hay method lookup", y las llamadas a metodos son simplemente indirecciones a partir de una tabla de punteros a funciones (vTable,
hablamos de C++ por ejemplo), pasa lo mismo para las funciones "virtuales" que son heredadas por las subclases. Porque también tiene que funcionar el polimorfismo.

Es verdad que en C++ como todo se resuelve en el momento de compilación esto se podriamos pensar que hay alguna otra forma de resolverlo. Pero la verdad es que no hay otra forma, porque por ejemplo, en Windows, podes tener subclases implementadas en una DLL que se linkea en tiempo de ejecucion, y entonces eso es algo que no se sabe en tiempo de
compilacion, es decir: hay que resolverlo por offsets fijos (o method lookups a partir de nombres)

es decir, el profesor ese estaba hablando metafóricamente, y se puede entender así:

Cuando instancias algo de una subclase, la nueva instancia tiene adentro (embebida, inlineada, incrustada) una instancia de la superclase

A lo mejor te sirve ésto:

Analisis del despacho dinamico de mensajes en lenguajes orientados a objetos

qué suerte que el texto de referencia tiene solamente unas 198 páginas.... xD



ya tengo con qué entretenerme hasta que vaya a buscar el 1er librito de la guia del viajero.... xD

Uh, me habia perdido las demas respuestas .

Gracias por la data, y por sacarme la duda

Buenas, perdón que me meta, nose como trabajan los motores de estos lenguajes, yo intuyo que en los lenguajes orientados a objetos de nueva generacion, vease java y C#, tiene logica crear instancias de las superclases, ya que al ser lenguajes tipados, se pueden ganar varias ventajas con esto... por ejemplo para generar polimorfismo tipado... yo a esa instancia de Auto la puedo meter en una colección de Transporte, lo que esta ahi adentro, sería la instancia de transporte relacionada con la instancia de auto (Da la sensacion de herencia )...

Ahora hablando de smalltalk, que es un lenguaje nativo en objetos, que no es tipado, nose si tiene mucho sentido hacer esto, acordate que en Smalltalk existe el method lookup, que cuando un objeto recibe un mensaje empieza a buscar el cacho de codigo a ejecutar, si no lo encuentra en la clase, va a la superclase.. y asi hasta llegar a Object, si no hay match te tira un "Does not understand", nose si tiene mucho sentido esa forma interna de trabajar en un lenguaje como smalltalk, pero podría ser

LeaTex escribió:A lo mejor te sirve ésto:

Analisis del despacho dinamico de mensajes en lenguajes orientados a objetos

Che está re buena esa tesis, me enganché leyendola en el laburo mal

con una mano en el corazón, chaito.... la leerias fuera del laburo?? xD