Hola Sebastián,

>El problema es que, en un LOO como java o smalltalk,

Disculpame por frenarte aqui... lo que pasa es que lo dijimos muchas veces
y en mi opinión es importante aclarar que "Smalltalk NO es un lenguaje"
tantas o mas veces que se escuche decir lo mismo...
Por lo general, quien no entiende las importancia de smalltalk
se refiere a smalltalk como un lenguaje; y es muy facil
escuchar referencias así en muchos "autodenominados" Smalltalkers
y listas de usuarios de smalltalk.
Aqui tratamos de preservar un espacio para pensar en otrs términos,
y por eso te voy a recomendar (y quizas otros también) que saques a
Smalltalk de esa lista de LOOs, porque auqneu soportes su sintaxis
(y semántica) estarás contribuyendo con tugranito de arena a que
la masa siga pensando en smalltalk como una sintaxis + un buen IDE.

>el envío de mensajes a objetos es hace síncronamente: el emisor
> se conjela hasta que el receptor responde.

Esto no está fijo en Smalltalk.
A que te referís con que "un objeto se congela" ?

Un objeto envía un mensaje a otro (el mensaje implica un receptor,
un selector y "argumentos" ) y listo...
nadie garantiza la "devolución" de un objeto; es algo que
ocurre frecuentemente, pero de ninguna forma está garantizada
la respuesta... por más voluntad y énfasis que ponga el emisor
en enviar el mensaje :-)

>De esta forma los
> "programadores de escritorio" asumimos que la respuesta forma
> parte del mensaje (o al menos esto me pasa a mi).

No. Me parece que estas pensando demasiado...

>Los mensjaes sincronos no son viables en el ámbito de la
> comunicación cliente servidor, por lo que debo analizar
> cuál es la forma más natural de exponer el problema al usuario.

A que te referís con natural?
(a veces se confunde "natural" con "invisible", con "atómica", etc.)
Si tenes una comunicación cliente-servidor... tenes esas dos clases
y allí decis como lo resuleven.. asi de simple.
Si queres probar con mas formas que puedan darse,
refinas usando lo de siempre (subclasificacion, etc)

>Entonces mi primera pregunta sería medio teorica y es:
>¿forma la respuesta parte del mensaje?(sinc)

No.

>¿o la respuesta en sí es un segundo mensaje?(asinc)

No.
Si tenes una respuesta... aRespuesta, es un objeto..
hace una clase, etc... asi de simple, como siempre.
Que aRespuesta herede de Message... te va a ser muy claro
de responder cuando (te canses de) dejes los términos teóricos
y lo resuelvas.

>Y mi segunda pregunta es más bien sobre la sintaxis.
> Los mensajes sincronos toman como síntaxis :
> "respuesta := objeto mensaje parametros",
>pero para los mensajes asíncronos ya no sería tan tribial.

No. La asignación no forma parte de un mensaje;
es solo eso, una asignación de nombre a un
objeto (una nominación).

>Todas las soluciones que se me han ocurrido implican al menos
> dos elementos nuevos que intervienen en el envío de
> un mensaje:
>1) notificación de la respuesta y
>2) la identificación explícita de mensajes.

Es muy simple de resolver, es algo que no requiere de mucha experiencia;
solo de hacer unas pruebas.
Podes tomar trabajos de otros sobre este tema, todos tiene la
misma base (trabajos en HP sobre distribución en 198ypico
y luego trabajos de otros, en los que me incluyo en 1990 aprox.
despues de eso tenes varias copias y alternativas planteadas en
varios smalltalk -squeak incluido- de varios años despues).

>Por último al acostumbrarnos a trabajar con mensajes asíncronos
> (por ejemplo ajax o invocación a WS) nos damos cuenta de que
> la forma de pensar en los objetos cambia,

jaja... ojalá alguna vez aparezcan mas heramientas para
dejar de "pensar" en objetos. :-)

> el código se espaguetiza más (el órden de las sentencias no
> se respeta al enviar un mensaje; el control salta a un handler
> para notificar una respuesta).
>Me gustaría saber cuál es la experiencia de los demás en estas
> situaciones, y si alguien conoce alternativas de síntaxis
> para "aliviar" este cambio.

En mi experiencia no hay cambios de sintaxis que realizar,
solo disponer de forma cuidadosa objetos del sistema
para lograr lo que se necesita.
Mucha gente habla de soluciones y herramientas tratando de
abstraer "el trabajo duro"... y parece que con más frecuencia
hace unos años, pero frecuentemente lo hacen para hacer que
los demás sientan que dependen de sus formulaciones maravillosas
y lograr así que la gente de sistemas cada vez menos pueda
hacer (por no haber resuelto nada por merito propio).

>Un saludo. Espero se halla entendido el problema.
> Cualquier sugerencia o lectura sobre el tema es bienvenida.
> Gracias por la paciencia ;)

Sugerencia: Implementate algo y dale vueltas hasta lograr tu propósito.
Quizás el "problema" esté en el propósito y no en otra parte
(me refiero que si no tenes uno o mas proyectos/contextos en dónde
trabajar resolviendo la distribución, solo vas a poder pensar, leer
y formular problemáticas, pero así no te acercas a ganar experiencia
sobre el tema, qu siempre es dependiente de hacer ciclos resolviendo
sistemas -con objetos- ).

espero sepas entender mis palabras, que son con el ánimo de
alentarte a hacer lo tuyo (crear tus objetos) y plantearte un camino
que no considere "los demás" que no están ahí para ayudarte...
Cuando a uno se le presenta el construir un sistema para un
usuario hipotético/abstracto, el primer paso es conseguir
usuarios de verdad; hast aque no haces esto, todo queda en
el plano de las fantasías/teorías (lo odioso de lo teórico es que no
está relacionado con una realidad sistémica, lo que uno piensa
no tiene relacion con objetos, sino con "algoritmos",estratégias,
y juegos... es en el fondo, una forma inhumana [*] de entender
las cosas)

suerte!
Ale.
[*] inhumana, pero tan usada, que hoy en día parece que es natural
y conveniente que los humanos entendamos así (sin tocar).


----- Original Message -----
From: "Sebastian Gurin" <sgurin@...>
To: <smalltalking@...>
Sent: Thursday, September 04, 2008 10:58 AM
Subject: [objetos] mensajes asíncronos


Hola a todos. Hace mucho que quiero escribir este mensaje pero la verdad no
me animaba pues me va a costar mucho explicarme. Lo intentaré de todas
formas

Estoy trabajando en un proyecto persona cuyo contexto es el del desarrollo
de aplicaciones web en donde el usuario escribe su aplicación en su lenguaje
orientado a objetos de escritorio preferido (java, python, smalltalk, igual
da) y un traductor genera el código javascript, html y css necesario para
representar la aplicación en forma web.

Como pasa con todos los traductores, hay formas, conceptos o tecnicas que no
son naturalmetne traducibles. En mi caso el problema es con los mensajes a
objetos remotos, es decir qué ofrecerle al usuario para el envío de mensajes
a objetos remotos de forma tal que le sea lo más natural posible.

El problema es que, en un LOO como java o smalltalk, el envío de mensajes a
objetos es hace síncronamente: el emisor se conjela hasta que el receptor
responde. De esta forma los "programadores de escritorio" asumimos que la
respuesta forma parte del mensaje (o al menos esto me pasa a mi).

Los mensjaes sincronos no son viables en el ámbito de la comunicación
cliente servidor, por lo que debo analizar cuál es la forma más natural de
exponer el problema al usuario.

Entonces mi primera pregunta sería medio teorica y es: ¿forma la respuesta
parte del mensaje?(sinc) ¿o la respuesta en sí es un segundo
mensaje?(asinc)

Y mi segunda pregunta es más bien sobre la sintaxis. Los mensajes sincronos
toman como síntaxis : "respuesta := objeto mensaje parametros", pero para
los mensajes asíncronos ya no sería tan tribial. Todas las soluciones que se
me han ocurrido implican al menos dos elementos nuevos que intervienen en el
envío de un mensaje: 1) notificación de la respuesta y 2) la identificación
explícita de mensajes.

Por último al acostumbrarnos a trabajar con mensajes asíncronos (por ejemplo
ajax o invocación a WS) nos damos cuenta de que la forma de pensar en los
objetos cambia, el código se espaguetiza más (el órden de las sentencias no
se respeta al enviar un mensaje; el control salta a un handler para
notificar una respuesta). Me gustaría saber cuál es la experiencia de los
demás en estas situaciones, y si alguien conoce alternativas de síntaxis
para "aliviar" este cambio.

Un saludo. Espero se halla entendido el problema. Cualquier sugerencia o
lectura sobre el tema es bienvenida. Gracias por la paciencia ;)

--
Sebastian Gurin <sgurin@...>

------------------------------------

Para más información sobre la Asociación escribir a info@...

Smalltalking es un espacio colaborativo creado para el estudio y desarrollo
en Ambientes de Objetos.
Se sustenta gracias a la participación de sus socios.

Las reglas de etiqueta sobre la lista están en
http://www.smalltalking.net/join/netiquete.htm
Enlaces a Yahoo! Grupos