Me parece que la jerarquia de Stream no esta linda porque seguimos usando la primera que se programo, basicamente. Nunca llegue a pensarlo del todo, pero a veces me parece que lo que hace falta es un Stream que tenga un read policy y un write policy, cosa de poder mezclar lo que quieras sin necesidad de pegotearlo antes de tiempo en una clase determinada...
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 >> > [email protected] >> >> >http://www.clubSmalltalk.org- 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 -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
