Hola Hernán, una pregunta, esto lo implementaron o es un trabajo teórico? (de cualquier manera me parece muy interesante)
Diego On Aug 2, 7:36 am, Hernan Wilkinson <[email protected]> wrote: > Alejandra De Bonnis es su tesis de licenciatura reifico el method lookup de > tal manera que cada objeto podía definir cómo buscar un método a partir de > un mensaje. De esta manera teníamos en el mismo ambiente prototipos y clases > por ejemplo. Haciendo esto usar dnu o method wrappers, etc. dejó de tener > sentido... imaginense, cada OBJETO puede definir que hacer cuando recibe un > mensaje (delegarlo, buscar su método, tomarlo prestado, etc). > Como dice Gaby, el problema de la regresión existió pero lo resolvirmos > fácil jeje... o sea, los objetos que se usaban para reificar el method > lookup no podía reificar su method lookup jeje, pero igual había que > trabajar un poco más en cómo estaba implementado. > A mi entender fue un trabajo muy pero muy interesante, lástima que como > muchas cosas quedó ahí muerto por falta de tiempo para investigar, guita > para invertir, etc. > En fin, si alguien tiene ganas de verlo avise > > Hernán. > > 2010/7/27 Gabriel Brunstein <[email protected]> > > > > > Diego, en realidad el method dictionary se puede modificar, y se pueden > > usar wrappers bastante sofisticados, como method wrappers o instance > > wrappers (con clases anónimas). Creo que vos te referís a tener reificado en > > Smalltalk el algoritmo de method lookup, cosa que sería muy interesante de > > ver como se resolvería (hay un problema de regresión infinita, ya que el > > propio algoritmo tendría que evaluarse utilizándose, algo loco..). Si esto > > se logra sería muy interesante para experimentar, pero no hay que subestimar > > el problema de performance que podría ocasionar. > > Por otro lado, según entiendo, lo que vos decías es tener un modelo de > > prototipos y delegación como el de Self (de donde se influenció > > NewtonScript). Yo también creo que sería más natural partir de un esquema > > de ese tipo y luego agregarle el esquema de clasificación como el de > > Smalltalk, así podrías combinar ambos. > > Pero creo que estos cambios implicarían un nuevo ambiente, ya no sería > > Smalltalk. Estaría muy bueno todo esto, pero por como están las cosas > > después de 35 años no creo que pase nada... > > > 2010/7/27 [email protected] <[email protected]> > > > Hola Andrés > >> Contesto entre líneas... > > >> On Jul 26, 8:57 pm, Andres Valloud <[email protected]> wrote: > >> > > Coincido en que hacer algo que ande es relativamente sencillo y hacer > >> algo que ande bien es extremadamente complejo. > > >> > Y si... tal cual. > > >> > > Entre las cosas que hoy le pediría a un VM es en que aumenten los > >> límites en cantidad de objetos, que soporten 64 bits > > >> > No es por ser pretencioso, pero VisualWorks tiene VMs de 64 bits para > >> > Linux en x86, Solaris en x86, y Solaris en SPARC. Trabajamos mucho > >> > con las VMs y las imagenes de 64 bits en este tiempo, y las versiones > >> > que estan a punto de salir son muchisimo mejores que lo que teniamos > >> > hace unos años (esto no lo digo yo o nosotros (Cincom)... lo puso por > >> > escrito gente de GemStone en la lista de VisualWorks acerca de 7.7). > > >> > Tambien estamos trabajando en un port a Windows 64 bits. Esto ultimo > >> > es mas dificil de lo que parece. Por ejemplo, al contrario de mas o > >> > menos todo el mundo, en Windows de 64 bits un long tiene 32 bits. Asi > >> > que si, digamos, tenes codigo multiplataforma que habla de longs todo > >> > el tiempo porque hasta ahora siempre (la VM de VisualWorks tiene cerca > >> > de 30 años encima) en 64 bits un long tenia 64 bits, y en 32 bits un > >> > long tenia 32 bits... hmmm... > >> Si, puedo imaginar a VW y Gemstone muy bien armados en todo eso, en mi > >> caso uso Dolphin o Squeak por motivos comerciales. > > >> > > y algo que siempre quisiera tener es mucho mas control sobre el method > >> lookup, que a mi entender es la principal limitación de Smalltalk. > > >> > Podrias contar mas de esto? Donde le ves la limitacion? Que te > >> > gustaria que hubiera pero no hay? > > >> Cuando envío un mensaje a un objeto, este busca en la clase, > >> superclases, etc. y ejectua el método. Toda esta convención es > >> invariable y define, sin posibilidad de modificar nada, cosas muy > >> importantes como la herencia y otras yerbas. Esta convención nos > >> parece bien a todos porque nos parece bien que si mando el mensaje > >> #print se ejecute el método #print, y también nos parece bien a todos > >> utilizar herencia simple, y también a casi todos nos parecen bien las > >> clases, metaclases y todo lo que defendemos desde la practicidad. Sin > >> embargo, no poder modificar esta convención, trae mas limitaciones de > >> las que generalmente pensamos (porque nos acostumbramos y nos gusta la > >> convención) y usualmente resolvemos de manera sucia y limitada. Son > >> conocidos los casos no muy bien resueltos con herencia simple (como la > >> jerarquia de Stream), son conocidos los trucos de usar #dnu para > >> activar métodos que no están presentes en la clase del receptor (como > >> en los proxies) y personalmente me molesta que esté conceptualmente > >> tan acoplado el método con el mensaje, dos cosas muy distintas. Una > >> solución que me suena factible, y tal vez compleja de implementar > >> decentemente, sería que el methodLookup estuviera implementado en > >> Smalltalk, en Object supongo. La implementación default podría ser una > >> primitiva que hiciera lo mismo que esperamos hoy en día, pero que al > >> modificarla en subclases nos abriera un campo de posibilidades muy > >> amplias y muy peligrosas (tan peligrosas como cualquier otra de > >> Smalltalk). Sería trivial implementar proxies, hacer delegaciones mas > >> sofisticadas y generar diseños hoy imposibles, de manera muy clara. > >> Por ejemplo, hoy es común ver que los proxies para persistencia en > >> bases de datos, o para sistemas distribuidos se hacen heredando de > >> ProtoObject, o de clases con pocos métodos, cosa que ya es sucia de > >> entrada, luego se agregan #dnu que son mas sucios. No sería mas > >> adecuado que la clase de un proxy fuera el misma que la del subject? > >> al menos parecida?, de esta manera se podrían delegar en el subject la > >> resolución de algunos métodos y en el proxy la resolución de otros, > >> podría incluso haber cooperación entre estos objetos. Esto es largo de > >> explicar, pero creo qeu se podría resolver mucho, programando poco, > >> mas claro y simple de debuggear. Otro ejemplo sería la herencia > >> múltiple, quedaría de una manera muy prolija, porque se podría acotar > >> a una parte muy pequeña del sistema, no estaría condicionada por otra > >> convención (como en c++), no tendría porqué tener que limitarse a > >> clases, podría ser entre objetos (como en la herencia de prototipos > >> que usaba en el NewtonScript de Apple). Es mas el polimorfismo se > >> ampliaría porque un objecto podría resolver mensajes que hoy no > >> entendería. Creo que también desaparecerían los intentos de solucionar > >> estos problemas mediante traits o cosas similares. Todo esto, tal vez > >> genere mas incertidumbre, pero creo que sería muy interesante TENERLO, > >> ir usándolo con mucho cuidado, y posiblemente aparezcan patterns que > >> mejoren sustancialmente las recetas actuales. Entiendo, no estoy > >> seguro, que las primeras versiones de la VM de Smalltalk tenían algo > >> similar y que luego se descartó por temas de perfomance, supongo que > >> 35 años mas tarde se podría tratar de resolver ese "problemita". > > >> Saludos > > >> Diego Coronel > > >> > Andres. > > >> > 2010/7/26 [email protected] <[email protected]>: > > >> > > Coincido con Gerardo, muy bueno el correo de Andrés, muchas gracias. > >> > > Sería bueno que alguna vez alguien documentara o publicara algo acerca > >> > > de VMs de calidad, hay poca gente que lo podría hacer bien, y ese > >> > > material aportaría a la continuidad de Smalltalk como plataforma a > >> > > largo plazo. Todo smalltalker alguna vez tiene su época de querer > >> > > hacerse la VM, yo la pasé y si me distraigo un poco supongo que > >> > > volveré a lo mismo, es como recurrente el tema. Coincido en que hacer > >> > > algo que ande es relativamente sencillo y hacer algo que ande bien es > >> > > extremadamente complejo. Además la problemática a resolver tiene poco > >> > > que ver con Smalltalk (lo cual no lo hace menos divertido). Me parecen > >> > > válidos todos los enfoques, desde los que arrancan del assembler mas > >> > > crudo hasta los que se suben arriba de otra VM o lenguaje de alto > >> > > nivel, cada uno en su lugar y contexto no deja de ser interesante. > >> > > Entre las cosas que hoy le pediría a un VM es en que aumenten los > >> > > límites en cantidad de objetos, que soporten 64 bits y algo que > >> > > siempre quisiera tener es mucho mas control sobre el method lookup, > >> > > que a mi entender es la principal limitación de Smalltalk. > > >> > > Pero insisto en que sería bueno, que quienes saben del tema, alguna > >> > > vez publiquen y/o hagan docencia sobre el tema, al menos a modo de > >> > > memorias antes de retirarse. Creo que muchos pagaríamos gustosos un > >> > > libro sobre eso, porque nos ahorraría tiempo en lo que igual queremos > >> > > o vamos a hacer. Y además, difundir esto podría tener un efecto > >> > > positivo y podría originar la aparición de mas alternativas que las > >> > > que existen hoy, que son pocas. > > >> > > Saludos y gracias por la información. > > >> > > Diego Coronel > > >> > > On Jul 26, 2:41 pm, Gerardo Richarte <[email protected]> wrote: > >> > >> excelente andres!!! > > >> > >> espero que todo esto tambi n lo tengas en formato powerpoint :) > > >> > >> ya sab s que a unos cuantos nos interesa, ponele una tonelada de > >> > >> detalles t cnicos, y agregale una pizca de rant tambi n :) > >> > >> listo! receta perfecta :) > > >> > >> en un rato vuelvo a leer el mail y mando algunas preguntas tambi > >> n > > >> > >> saludos! > > >> > > -- > >> > > To post to this group, send email to [email protected] > >> > > To unsubscribe from this group, send email to > > ... > > read more »- Hide quoted text - > > - Show quoted text - -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
