unlp Me dijeron que era la mejor universidad de Argentina... parece que no ;-)
Y si es tan complicado, ¿porqué no los cuentas dónde están las complicaciones? ¿O no saber cómo hacerlo te convierte en experto como para decir que nadie más lo puede hacer o cuál es el camino equivocado? Sos genial!!! No sabes cuánto me hacés reir. :)) En todo caso es una falacia típica. Lo mismo que hace Alan Turing cuando dice que si su máquina es indecidible entonces todas lo son. Primero encuentra el problema equivocado, luego plantéalo de la manera equivocada, luego presenta una solución que no lo resuelve y que es la solución más general posible... ¿No se han preguntado porqué todos estudiamos la indecibilidad de la máquina de Turing universal? Si eso no es crear the "dark ages", no sé lo que es. Ejemplos hay muchos: http://cssbl.com/frases-01.htm Ahora yendo específicamente al tema de los objetos distribuidos, no veo porqué sería complicado si puedes: 1. Serializar un objeto (convertirlo en String). 2. Enviarlo por un socket. 3. Deserializarlo al otro lado. Quizás te imaginas que el problema es que las transacciones distribuidas no podrían funcionar. Eso lo resuelven las bases de datos con 2 phase commit. Si estamos hablando de transacciones en memoria (todo en Smalltalk, como me imaginaría a GemStone, sin una base de datos como Oracle por debajo), existe memoria transaccional. Y bueno se puede seguir escarbando, todas esas cosas están resueltas, pero nótese que J2EE (y por ende EJB) sólo llega a la base de datos, no hace ninguna transacción en memoria y esa es la razón por la que los EJB deben ser stateless y no stateful. Si son stateful entonces no hay manera de hacer participar a esos objetos de las transacciones de la base de datos. Ok, si tenemos memoria transaccional e implementamos 2 phase commit en memoria se podría, pero ¿para qué? ¿qué caso de uso lo requiere realmente? Generalmente todas las transacciones se pueden resolver a nivel de base de datos, y por lo menos a mí nunca me ha tocado que sea necesario hacerlo a nivel de RAM. De hecho prefería implementar un SQL en Smalltalk con transacciones y todo que tener que generar engendros que no son ni una cosa ni la otra. (De hecho SQL está implementado en C y en Java, no veo ninguna razón para no poder implementarlo en Smalltalk). Saludos, Guillermo. On Mon, 2010-10-11 at 17:50 -0300, andres wrote: > Guillermo Schwarz escribió: > > Por lo visto ustedes tienen tan claro como yo como implementar todo > > esto. > > No, para nada! Justamente por eso esperaba que vos me mostraras cómo; > todo lo que vos considerás trivial yo lo considero complicadísimo y que > lleva meses de implementación, de ahí mi curiosidad. Una pena que no te > sirva de mucho hacerlo :( > > > Bueno, al menos lo que mencionaba respecto de thisContext está > > implementado en Pharo. > > > > Basta con imprimir: > > > > thisContext sender > > > > y se ve que funciona. > > Si, tal cual! De ahí ya estamos a un pasito nomás. Grosso, no? > > Bueno, creo que este thread ya no da para mas. > > Saludos! > Andrés > -- Simplex Veri Sigillum -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
