[clubSmalltalk] Re: Comportamiento de la instancia ????

Wed, 08 Nov 2006 04:41:10 -0800

En C++ lo que falla de los mensajes es que no pueden ser pasados como parámetros como se hace en Smalltalk, en el que son símbolos, por ejemplo #new.

En Smalltalk se hace diferencia entre el método y el mensaje porque el mismo mensaje (invocación) puede invocar diferentes métodos (implementaciones).
 
En C++ pasa lo mismo con la VMT = Virtual Method Table. Claro que la nomenclatura en C++ no es tan limpia como en Smalltalk, porque en C++ los métodos se llaman member functions, ¿entonces para qué necesito una VMT? Debería llamarse virtual member function table.
 
Respecto de la delegación dinámica, creo que basta con el patrón Comando. Si se generan clases que representan acciones, luego basta con indicar la acción que representa la clase. Lo mismo ocurre con el patrón Factory y con el strategy que te permite apuntar a diferentes implementaciones en runtime.
 
En particular los tipos que han inventado estos patrones, que curiosamente son los mismos que inventaron XP, las CRC cards, etc. indican que la utilidad de los patrones es que hacen más dinámica la orientación a objetos. De hecho hay un único patrón que utiliza la herencia propiamente tal y el template method, el resto la usa o la ignora. La crítica que hacen de la herencia es que ella rompe la encapsulación, básicamente porque la clase derivada puede ver las variables de instancia de la superclase, y de esa manera puede romper el invariante de la superclase.
 
En traits eso no existe, porque los traits no tienen variables de instancia, sino que todo método se define en función de otros métodos, hasta llegar a métodos abstractos por definir. Yo lo probé y me gustó, porque no tiene ninguna de las desventajas de la herencia mútiple, ni de los mixins.
 
Saludos,
Guillermo.
 
On 11/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Yo no lo vi implementado, aunque alguien me dijo alguna vez que
Smalltalk 74 era asi, y coincido en que estas cosas hay que probarlas,
tal vez durante un largo tiempo, de hecho llevó mucho tiempo darse
cuenta de los problemas de la herencia mútiple. En C++ ni siquiera hay
mensajes, yo diría que son llamadas a métodos. Además el punto es
que la delegación sea dinámica, no bastaría con hacer una
delegación arbitraria pero estática, o sea que de antemano se sepa a
quién se va a delegar.

DIego

On Nov 6, 6:45 pm, "Guillermo Schwarz" <[EMAIL PROTECTED] >
wrote:
> ¿Pero eso está implementado en alguna parte?
>
> No es por ser abogado del diablo, pero creo que habría que partir por un
> prototipo, por ejemplo en Squeak, para ver si efectivamente tiene buen
> desempeño o sólo es wishful thinking...
>
> ¿Es idea mía o eso de delegar a cualquier otro método de cualquier otra
> clase ya está implementado en C#?
>
> Saludos,
> Guillermo.
>
> On 11/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > Guillermo,
> > No es que tenga que ser una cosa o la otra, si la resolución de los
> > mensajes fuese algo flexible y no prefijado en la VM entonces esas
> > técnicas que nombras serían solo patterns. Esto es bueno porque no
> > hay que bancárselo en todo el sistema como una regla general, pero
> > principalmente porque aparecerían muchas alternativas mas. Suponer que
> > la herencia mútiple o los traits son buenos o malos es una
> > consecuencia de la limitación que recalco.
> > Saludos,
> > Diego
>
> > On Nov 5, 7:11 pm, "Guillermo Schwarz" <[EMAIL PROTECTED] >
> > wrote:
> > > Me parece limpia la implementación de proxies usando #doesNotUnderstand.
>
> > > En Java existe lo mismo usando la interfaz InvocationHandler, pero el
> > > usuario debe definir una interfaz para cada clase que desea proxear, el
> > paso
> > > de parámetros y la instanciación son sintáticamente difíciles de
> > entender
> > > (en promedio les toma entre 3 meses y 1 año entenderlo).
>
> > > No entiendo la ventaja de que todas las clases estuvieran
> > automáticamente
> > > proxiadas. ¿Sería para evitarse en #doesNotUnderstand? Creo que es muy
> > > limpio que sólo se deba implementar un único método, además es mucho más
> > > eficiente que sólo se porxee las clases que lo necesitan.
>
> > > Por otro lado ¡qué tienen de malo los traits?
>
> > > On 11/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED] > wrote:
>
> > > > Cuando queremos que un objeto responda a mensajes que no están en su
> > > > protocolo, implementamos el método #doesNotUnderstand: (dnu) y ahi
> > > > agregamos comportamiento. Eso es típico en proxies. IMHO esto se
> > > > vería muy mejorado si todos los mensajes del sistemas pasaran por un
> > > > dispatcher previo, que no solo hiciera evitar este truco del dnu, sino
> > > > que también pudiera delegar la resolución del mensaje a cualquier
> > > > otro método de cualquier otra clase.
> > > > Ni mixins, ni traits, ni herencia mútiple a la C++ me convencieron
> > > > nunca. Comparto la idea de que el problema existe y que jerarquías
> > > > como Stream lo demuestran, pero creo que la solución es mas simple que
> > > > las sofisticaciones que se proponen. Simplemente sacando esta
> > > > funcionalidad de la VM tendríamos todo sin alterar la esencia del
> > > > ambiente. En la soluciones tradicionales a este problema se tiende a
> > > > hacer mas complejo el lookup, en cambio creo que habría que
> > > > orientarnos a desacoplar mas el mensaje del método, los objetos
> > > > deberían contestar mas seguido a mensajes que no son parte de su
> > > > protocolo.
>
> > > > Saludos,
> > > > Diego
>
> > > > On Nov 3, 7:06 pm, "Guillermo Schwarz" < [EMAIL PROTECTED]>
> > > > wrote:
> > > > > ¿Qué es dnu?
>
> > > > > No conozco un lenguaje OO que implemente bien la herencia múltiple.
> > Ni
> > > > C++
> > > > > ni Eifel caen en esa categoría.
>
> > > > > Para implementar alternativas a la herencia múltiple en Smalltalk
> > > > existen:
>
> > > > > 1. Los mixins.
> > > > > 2. Los traits.
>
> > > > > Hasta donde he visto los mixins no funcionan tan bien como los
> > traits.
>
> > > > > Saludos,
> > > > > Guillermo.
>
> > > > > On 11/3/06, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote:
>
> > > > > > El hecho de que #lookup no esté implementado fuera de la VM es una
> > da
> > > > > > las grandes falencias de Smalltalk a mi entender. Si eso fuera asi
> > > > > > tendríamos herencia mútiple (mas sofisticada), no haríamos abuso
> > de
> > > > > > dnu, no usaríamos proto-objects para hacer proxies, los proxies
> > > > > > podrían ser mas sofisticados, bajaríamos la cantidad de argumentos
> > en
> > > > > > muchos métodos y principalmente habría muchas mas opciones de
> > diseño
> > > > > > que hoy no existen por esa fuerte y prohibitiva relación entre
> > > > > > mensajes y métodos. Hay buenas razones relacionadas con los
> > actuales
> > > > > > diseños de VMs para que eso no sea como quisiera, supongo que
> > habría
> > > > > > que modificar muy a fondo las cosas para repararlo.
>
> > > > > > Diego- Hide quoted text -- Show quoted text -- Hide quoted text --
> > Show quoted text -- Hide quoted text -- Show quoted text -



--~--~---------~--~----~------------~-------~--~----~
  Ha recibido este mensaje porque está suscrito a Grupo "clubSmalltalk" de Grupos de Google.
 Si quieres publicar en este grupo, envía un mensaje de correo
electrónico a [email protected]
 Para anular la suscripción a este grupo, envíe un mensaje a [EMAIL PROTECTED]
 Para obtener más opciones, visita este grupo en http://groups-beta.google.com/group/clubSmalltalk?hl=es.
-~----------~----~----~----~------~----~------~--~---

Responder a