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 - --~--~---------~--~----~------------~-------~--~----~ 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. -~----------~----~----~----~------~----~------~--~---
