__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

Hola,

> Primero que nada, mil perdones por (1) no haber leído la discusión previa
> sobre MVC

Esta todo bien, lo decía pues allí hay más material.

>(2) dar mis conocimientos en cuanto a patrones de diseño en la
> prog. orientada a objetos sin hacer ninguna referencia a Smalltalk.

El tema de patrones es bastante sensible a que herramientas de
  producción uses, pues el uso de patrones implica una limitación
  en la expresión de las ideas por parte de las herramientas que
  usamos.
Hay muchos patrones que se han definido últimamente, gracias a
  las limitaciones en metaprogramación y programación existente
  en Java y/o C++.

> Sí, ya se que la mayoría de los smalltalks (al menos los Squeak viejos
antes
> de morphic) cuentan con el framework mvc para desarrollar guis.

Antes y después de morphic :-)
Si te fijás en mas detalle, el framework de MVC no es solo
  útil en desarrollo de interfaces...
Desde su primera formulación (1987?), ha sido el armado de
  GUIs su ejemplo de uso mas ejercitado (incluso para su
  enseñanza); y por esta razón la mayoría de nosotros pensamos
  que solo sirve para guis...
El mecanismo de cambios (change/update y sus variantes)
  que es necesario para la notificaciones entre las partes,
  está planteado en Object...
  es decir, el framework MVC se aplica a cualquier Object,
  en situaciones dadas en una triada MVC.

> Sin embargo, tenemos una confusión de nombres: MVC
> también es un patrón de diseño (design
> pattern) que resuelve el problema del diseño de aplicaciones con
interfaces
> gráficas complejas (mucha interacción con el usuario).

Que sería un pattern mas específico que un framework...
  no te parece raro?

> Nuestra confusión es
> consecuencia de que dicho design pattern fue creado en un Smalltalk y al
> parecer también implementado en un framework con el mismo nombre.

No. Ocurrió al revés.
Muchos patterns fueron escritos por quienes ya tenían experiencia
  de uso de frameworks (en Smalltalk); y generaron material para
  quienes no tenían herramientas iguales de potentes (para Java y
  otros);.... o para quienes no trabajan con objetos (diseñan, y hacen
  dibujos; en vez de construir sistemas).
Los patterns se definieron mucho tiempo después que
  se maduraran frameworks de poder en Smalltalk.
El caso de MVC es uno de los mas interesantes,
  pero creo que hoy en día ya no queda mucha información
  para hacer un trazado histórico.

> Por
> ejemplo en java, el design pattern mvc está implementado en muchos
> frameworks orientado a diferente tipos de trabajo, desde guis (graphic
> eclipse framework) a aplicaciónes webs (struts).

El que esté implementado en mas de un framework indica una
  limitación en las herramientas o en la comunidad (no generó
  consenso como para madurar un framework).

> Dado que me pareción una discusión sobre design patterns, yo estaba
hablando
> del design pattern mvc y no de un framework que lo
implementara/se-basara-en
> mvc.

Cómo un pattern es una formalización (un texto no ejecutable)
  su nivel de abstracción es altísimo y lo pone como raíz de
  muchas cosas... pero esta alta abstracción es lo que implica
  que hay que ponerle muchisima energía para hacerlo algo
  de valor en un contexto dado.
La existencia de un framework no es poca cosa, sino que
  requiere de muchisima menos energía y riesgo su uso/adopción.

Los frameworks también son abstractos y requieren, por eso
  de energía para su instanciación, que de por si, no es poca;
  y según entiendo, la mayoría d elas personas que implementan
  patterns lo hacen sin antes ganar experiencia en frameworks
  existentes (cosa que antes de la aparición de patterns se veía
  menos, pues Smalltalk era mas usado en la enseñanza).

Una de las razones a mi entender del uso de Morphic esta
  dada por la gente que lo usa; es decir, por el desconocimiento
  general en el uso de MVC; mas la inexistencia (adrede) de alternativas
  decorosas en Squeak para la resolución de interfaces convencionales.

hasta pronto,
Ale.




----- Original Message -----
From: "Sebastián Gurin" <sgurin@...>
To: <smalltalking@...>
Sent: Wednesday, March 29, 2006 9:50 AM
Subject: Re: [objetos] Re: [OT] Patron Command


> Hola Alejandro.
>
> Primero que nada, mil perdones por (1) no haber leído la discusión previa
> sobre MVC y (2) dar mis conocimientos en cuanto a patrones de diseño en la
> prog. orientada a objetos sin hacer ninguna referencia a smalltalk.
>
> Te contesto entre líneas:
>
> ----- Original Message -----
> From: "Alejandro F. Reimondo" <aleReimondo@...>
> To: <smalltalking@...>
> Sent: Tuesday, March 28, 2006 7:29 PM
> Subject: Re: [objetos] Re: [OT] Patron Command
>
>
> > Sebastián,
> > Mi intensión (con las líneas siguientes) no es ser molesto,
> > sino dar lugar a algún diálogo usando estos temas,
> > como motivantes a reflexiones relacionadas con
> > nuestros objetivos.... no me maldigas por usar unas
> > palabras de tus párrafos, me parecieron buenas para
> > acotar: [*]
> >
> >>Es muy usado con el patrón de diseño
> >> model-view-controller,
> >
> > MVC es un framework, no un patrón (hace un tiempo
> > hablamos bastante de las diferencias, si alguien
> > quiere podríamos repetir el diálogo, ya que la
> > otra vez, creo que fue enriquecedor).
> > Por otro lado un patrón, no puede usarse;
> > sino solamente instanciarse.
> >
>
> Sí, ya se que la mayoría de los smalltalks (al menos los squeak viejos
antes
> de morphic) cuentan con el framework mvc para desarrollar guis. Sin
embargo,
> tenemos una confusión de nombres: MVC también es un patrón de diseño
(design
> pattern) que resuelve el problema del diseño de aplicaciones con
interfaces
> gráficas complejas (mucha interacción con el usuario). Nuestra confusión
es
> consecuencia de que dicho design pattern fue creado en un smalltalk y al
> parecer también implementado en un framework con el mismo nombre. Por
> ejemplo en java, el design pattern mvc está implementado en muchos
> frameworks orientado a diferente tipos de trabajo, desde guis (graphic
> eclipse framework) a aplicaciónes webs (struts).
>
> Dado que me pareción una discusión sobre design patterns, yo estaba
hablando
> del design pattern mvc y no de un framework que lo
implementara/se-basara-en
> mvc.
>
> >>se los mande a algún singleton del modelo
> >
> > Por la misma razón uno no podría enviarle mensajes
> > a un singleton... ya que singleton es un patrón :-)
> > (y no un objeto concreto).
> >
>
> Esto sí está bien. Igualmente, por lo menos en los contextos de trabajo
que
> me han tocado hasta ahora, decir "el singleton X" significa, dentro de
algún
> software, la (única) instancia de la clase X que es singleton.
>
> > Esto lo digo con ganas de motivarnos a pensar
> > (y hablar, si desean) sobre los elementos abstractos,
> > su utilidad real...
> >
>
> en esto tienes razón.
>
> > con buena onda,
> > Ale.
> > [*] puse este prologo para evitar una mala impresión,
> > cosa que casi siempre ocurre cuando uno objeta
> > detalles sobre párrafos de los que no se espera
> > comentarios.
>
> Vale la aclaración. Igualmente, la lista ha siempre tenido un espíritu
> constructivo en todo aspecto. Nunca esperaría "mala onda" de nadie.
>
> Saludos!
> >
> >
> >
> > ----- Original Message -----
> > From: "Sebastián Gurin" <sgurin@...>
> > To: <smalltalking@...>
> > Sent: Tuesday, March 28, 2006 2:50 PM
> > Subject: [objetos] Re: [OT] Patron Command
> >
> >
> > Hola. Te tiro un ejemplo de uno de los casos más comunes del patrón de
> > diseño command.
> >
> > Con el patrón sommand se trata de encapsular una orden (por ejemplo,
> > (cambiarColor, objeto1, rojo)) en un objeto. Casi siempre se realiza
> > construyendo una gerarquía de comandos (clases). Es muy usado con el
> > patrón
> > de diseño model-view-controller, en el cual lo primero que queremos es
> > hacer
> > que las capas model (dominio, modelo lógico del problema/programa) y
view
> > (presentación/interacción con el usuario) sean independientes. En este
> > caso
> > se estila a que el controller interprete las acciones/eventos del
usuario,
> > instancie comandos (objetos que representan órdenes) y se los mande a
> > algún
> > singleton del modelo para que este efectúe los cambios en el modelo.
> >
> >
> >  -----Mensaje original-----
> >  De: smalltalking@...
> > [mailto:smalltalking@...]En nombre de leonardo stortoni
> >  Enviado el: Lunes, 27 de Marzo de 2006 10:36 a.m.
> >  Para: smalltalking@...
> >  Asunto: [objetos] [OT] Patron Command
> >
> >
> >  Que tal a todos :
> >
> >   No se si es el lugar apropiado pero bueno , queria saber si alguien me
> > puede dar una mano con el patron command , estuve viendo en el libro de
> > gamma y la verdad que no entiendo bien el ejemplo , alguien tendria por
> > casualidad un ejemplito en el que se vea claramente el por que usar este
> > patron!!!!!!!!.
> >
> >  PD  alguein tiene en formato electronico el libro "head first design
> > pattern" me han dicho que es muy bueno y facil de entender.
> >
> >  Saludos.
> >  __________________________________________________
> >  Correo Yahoo!
> >  Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
> >  ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar
> >
> >  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 de Yahoo! Grupos
> >
> >    a.. Para visitar el sitio web del grupo, andá a:
> >    http://ar.groups.yahoo.com/group/smalltalking/
> >
> >    b.. Para cancelar tu suscripción a este grupo, enviá un mensaje a:
> >    smalltalking-unsubscribe@...
> >
> >    c.. El uso de Yahoo! Grupos está sujeto a las Condiciones del
servicio
> > de Yahoo!.
> >
> >
> >
> >
> > 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 de Yahoo! Grupos
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
> 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 de Yahoo! Grupos
>
>
>
>
>
>

Hola,

> Igualmente, para mi squeak, una expresión |a| no define un nombre sino un
> "UndefinedObject". Las instancias de esta clase, al parecer, solo pueden
> tener el valor nil, que significa que el objeto no se ha definido aún o
que
> el resultado de un método no tiene significado. ;-)

Si no usas "a"... no se crea ningún objeto.
No es correcto que se cree un objeto (o que se realice una
  acción) cuando aún no es necesario.

Por eso, en realidad lo relevante es la asignación (de nombre);
  y no la "definición/creación de un nombre".
  (un buen compilador Smalltalk, genera bytecodes relacionados con
  la manipulación del objeto, solo al ser usado, y no antes; ya que es
  una de las razones de mayor pérdida de perfomance la alocación
  de contextos - y posterior reuso/desalocación- )

Un detalle, que puede servir es el relacionado con la sintaxis
  para definir los nombres al comienzo de un contexto. La UNICA
  razón de su necesidad tiene que ver con el análisis semántico
  del compilador (que es usado en el caso de compilar texto a métodos).
Por ejemplo, si abrís un workspace, verás que no es
  necesario (en el workspace) definir un nombre antes de usarlo;
  y sin embargo es necesario en un browser al escribir método...
A mi entender esto es un remanente arcaico de la "furia"
  de corregir antes de evaluar (característico de diseñadores
  de lenguajes :).

Es verdad que uno de los errores de tipeo mas frecuentes
  se dan en los nombres de objetos, pero esto debería incitarnos
  a tener un mecanismo que nos libere del problema, en vez de
  seguir padeciendo los inconvenientes de tipear textos (código :).

hasta pronto,
Ale.



----- Original Message -----
From: "Sebastián Gurin" <sgurin@...>
To: <smalltalking@...>
Sent: Wednesday, March 29, 2006 10:17 AM
Subject: Re: [objetos] Sobre los bloques | |


> Muy buena aclaración. Y como dices ¡qué atado estamos todavía a las
> tecnologías tradicionales!
>
> Igualmente, para mi squeak, una expresión |a| no define un nombre sino un
> "UndefinedObject". Las instancias de esta clase, al parecer, solo pueden
> tener el valor nil, que significa que el objeto no se ha definido aún o
que
> el resultado de un método no tiene significado. ;-)
>
>
> ----- Original Message -----
> From: "Alejandro F. Reimondo" <aleReimondo@...>
> To: <smalltalking@...>
> Sent: Tuesday, March 28, 2006 1:23 PM
> Subject: Re: [objetos] Sobre los bloques | |
>
>
> > Hola,
> >
> > Lo que comenta Esteban es correcto, pero... :-)
> > permítanme aprovechar la oportunidad para recordar
> > que no es correcto hablar "variables" sino de nombres.
> > Le damos nombres a los objetos, y en el caso de usar
> > el compilador (de clase Compiler) que viene en Smalltalk,
> > es necesario declarar los nombres que se les darán a
> > objetos en un contexto.
> > Si mal no recuerdo hemos hablado, varias veces de este
> > tema y pueden encontrar bastante detalle en esta lista.
> >
> > Un tema directamente relacionado con este, es la asignación,
> > por ejemplo:
> >    a := 12 factorial.
> > indica le damos nombre "a" al objeto que se obtiene de
> > enviarle el mensaje factorial al objeto de nombre (universal) "12".
> > Vean que no es un asignación de variable, como, por ejemplo,
> > en pascal; dónde se utiliza el mismo espacio de memoria para
> > representar un dato.
> > Al trabajar con objetos nos liberamos de la arquitectura de
> > soporte (la memoria puede ser no direccionable, y/o el medio
> > de almacenamiento puede ser no reutilizable) y por eso el
> > contenido de un objeto es menos relevante que su nombre.
> > Fijense el valor que tiene el nombre excede a la clase del objeto...
> > Cuando decimos:
> >  aPen := self surface pen.
> > estamos nominando un objeto y ese nombre tiene un peso
> > muy importante en el contexto (un peso tal que determina su rol)
> >
> > Junto a ese valor que le damos al nombre, se suma la
> > importancia de la identidad del objeto, por eso, al hacer:
> >   b := a.
> > estamos dándole un nuevo nombre al MISMO objeto
> > y no estamos copiando nada... (como seria el caso de tener
> > "variables")
> > Idem al hacer
> >    c := b := a := d := nil.
> > solo damos mas nombres al mismo objeto que se llama "nil",
> > no copiamos objetos...
> >
> > Volviendo a la consulta de Lord ZealoN, quien seguramente
> > se le ha hecho una confusión con el tema de bloques,
> > creo que vale reflexionar un poco sobre la necesidad de
> > las barras para "definir los nombres antes de usarlos",
> > y su vínculo (en mi opinión fuerte) con el estar usando texto
> > para expresar comportamiento.
> > La secuencialidad del texto, mas la distracción que implica
> > usar una sintaxis; nos impone reglas que no sería necesario
> > adoptar en el caso de usar directamente objetos para
> > expresar comportamientos; en cuyo caso, el verlo es
> > suficiente para enviarle un mensaje, y no es necesario
> > nominarlo explícitamente.
> >
> > En este punto (y algunos mas) es donde el ambiente padece
> > aún hoy, +30años después, falta de avances; debidos quizás
> > a esa pesada herencia con los lenguajes de programación.
> > Como el llamar "variables de instancia" a los nombres
> > de las partes de un objeto...
> > O clases a las especies...
> >
> > Llevará mas de 30 años el poder desprendernos de esas
> > marcas históricas?
> > Es sorprendente cómo con una lectura un poco crítica,
> > se pueden ver los límites culturales que se auto impusieron
> > los diseñadores de Smalltalk; y es sorprendente como hoy
> > en día se quedan mudos cuando uno se los nombra :-)
> > Si, si... no podemos pedirle que cambien a quienes han
> > ya hecho mucho, pero porque no presentar ideas nuevas
> > a la gente nueva?
> >
> > hasta pronto,
> > Ale.
> >
> >
> >
> >
> > ----- Original Message -----
> > From: "Esteban A. Maringolo" <eMaringolo@...>
> > To: <smalltalking@...>
> > Sent: Tuesday, March 28, 2006 11:54 AM
> > Subject: Re: [objetos] Sobre los bloques | |
> >
> >
> >> Lord ZealoN escribió:
> >> > Estoy leyéndome el fantástico libro de Diego, pero no me ha quedado
> >> > claro el tgema de los bloques
> >>
> >> > | size |
> >> > size := self basicSize.
> >> > ^self
> >> > replaceBytesOf: (ByteArray new: size)
> >> > from: 1 to: size startingAt: 1.
> >>
> >> > El | size |  que es? sería equivalente a declarar variables por
> >> > ejemplo?
> >>
> >> Lo contenido entre | | no es un bloque, sino que es parte de la
> >> pequeña sintaxis de Smalltalk, se utiliza para declarar variables
> >> temporales en un contexto.
> >>
> >> En el caso de los métodos son temporales a la ejecución de dicho
> >> método, por lo que cuando el método retorna, los objetos
> >> referenciados por la variable quedan a disposición del garbage
> >> collector.
> >>
> >> En el caso de bloques tenes dos tipos de variables, las de
> >> argumentos de evaluación, y las temporales al bloque.
> >>
> >> Por ej:
> >>
> >> 1 to: 10 do: [:index | Transcript display: index; cr ]
> >>
> >> En este caso, :index es la declaración de una variable temporal del
> >> bloque, pero a nivel argumento.
> >>
> >>
> >> 1 to: 10 do: [:index |
> >> | esPar |
> >> esPar := index even.
> >> Transcript
> >> display: index;
> >> space;
> >> display: esPar;
> >> cr
> >> ]
> >>
> >> En este ultimo ejemplo, :index es una variable de argumento y esPar
> >> es una variable temporal del bloque.
> >>
> >> Saludos.
> >>
> >> --
> >> Esteban.
> >>
> >>
> >>
> >> 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 de Yahoo! Grupos
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> > 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 de Yahoo! Grupos
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
> 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 de Yahoo! Grupos
>
>
>
>
>
>
>

Hola Alejandro.

Primero que nada, mil perdones por (1) no haber leído la discusión previa
sobre MVC y (2) dar mis conocimientos en cuanto a patrones de diseño en la
prog. orientada a objetos sin hacer ninguna referencia a smalltalk.

Te contesto entre líneas:

----- Original Message -----
From: "Alejandro F. Reimondo" <aleReimondo@...>
To: <smalltalking@...>
Sent: Tuesday, March 28, 2006 7:29 PM
Subject: Re: [objetos] Re: [OT] Patron Command


> Sebastián,
> Mi intensión (con las líneas siguientes) no es ser molesto,
> sino dar lugar a algún diálogo usando estos temas,
> como motivantes a reflexiones relacionadas con
> nuestros objetivos.... no me maldigas por usar unas
> palabras de tus párrafos, me parecieron buenas para
> acotar: [*]
>
>>Es muy usado con el patrón de diseño
>> model-view-controller,
>
> MVC es un framework, no un patrón (hace un tiempo
> hablamos bastante de las diferencias, si alguien
> quiere podríamos repetir el diálogo, ya que la
> otra vez, creo que fue enriquecedor).
> Por otro lado un patrón, no puede usarse;
> sino solamente instanciarse.
>

Sí, ya se que la mayoría de los smalltalks (al menos los squeak viejos antes
de morphic) cuentan con el framework mvc para desarrollar guis. Sin embargo,
tenemos una confusión de nombres: MVC también es un patrón de diseño (design
pattern) que resuelve el problema del diseño de aplicaciones con interfaces
gráficas complejas (mucha interacción con el usuario). Nuestra confusión es
consecuencia de que dicho design pattern fue creado en un smalltalk y al
parecer también implementado en un framework con el mismo nombre. Por
ejemplo en java, el design pattern mvc está implementado en muchos
frameworks orientado a diferente tipos de trabajo, desde guis (graphic
eclipse framework) a aplicaciónes webs (struts).

Dado que me pareción una discusión sobre design patterns, yo estaba hablando
del design pattern mvc y no de un framework que lo implementara/se-basara-en
mvc.

>>se los mande a algún singleton del modelo
>
> Por la misma razón uno no podría enviarle mensajes
> a un singleton... ya que singleton es un patrón :-)
> (y no un objeto concreto).
>

Esto sí está bien. Igualmente, por lo menos en los contextos de trabajo que
me han tocado hasta ahora, decir "el singleton X" significa, dentro de algún
software, la (única) instancia de la clase X que es singleton.

> Esto lo digo con ganas de motivarnos a pensar
> (y hablar, si desean) sobre los elementos abstractos,
> su utilidad real...
>

en esto tienes razón.

> con buena onda,
> Ale.
> [*] puse este prologo para evitar una mala impresión,
> cosa que casi siempre ocurre cuando uno objeta
> detalles sobre párrafos de los que no se espera
> comentarios.

Vale la aclaración. Igualmente, la lista ha siempre tenido un espíritu
constructivo en todo aspecto. Nunca esperaría "mala onda" de nadie.

Saludos!
>
>
>
> ----- Original Message -----
> From: "Sebastián Gurin" <sgurin@...>
> To: <smalltalking@...>
> Sent: Tuesday, March 28, 2006 2:50 PM
> Subject: [objetos] Re: [OT] Patron Command
>
>
> Hola. Te tiro un ejemplo de uno de los casos más comunes del patrón de
> diseño command.
>
> Con el patrón sommand se trata de encapsular una orden (por ejemplo,
> (cambiarColor, objeto1, rojo)) en un objeto. Casi siempre se realiza
> construyendo una gerarquía de comandos (clases). Es muy usado con el
> patrón
> de diseño model-view-controller, en el cual lo primero que queremos es
> hacer
> que las capas model (dominio, modelo lógico del problema/programa) y view
> (presentación/interacción con el usuario) sean independientes. En este
> caso
> se estila a que el controller interprete las acciones/eventos del usuario,
> instancie comandos (objetos que representan órdenes) y se los mande a
> algún
> singleton del modelo para que este efectúe los cambios en el modelo.
>
>
>  -----Mensaje original-----
>  De: smalltalking@...
> [mailto:smalltalking@...]En nombre de leonardo stortoni
>  Enviado el: Lunes, 27 de Marzo de 2006 10:36 a.m.
>  Para: smalltalking@...
>  Asunto: [objetos] [OT] Patron Command
>
>
>  Que tal a todos :
>
>   No se si es el lugar apropiado pero bueno , queria saber si alguien me
> puede dar una mano con el patron command , estuve viendo en el libro de
> gamma y la verdad que no entiendo bien el ejemplo , alguien tendria por
> casualidad un ejemplito en el que se vea claramente el por que usar este
> patron!!!!!!!!.
>
>  PD  alguein tiene en formato electronico el libro "head first design
> pattern" me han dicho que es muy bueno y facil de entender.
>
>  Saludos.
>  __________________________________________________
>  Correo Yahoo!
>  Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
>  ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar
>
>  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 de Yahoo! Grupos
>
>    a.. Para visitar el sitio web del grupo, andá a:
>    http://ar.groups.yahoo.com/group/smalltalking/
>
>    b.. Para cancelar tu suscripción a este grupo, enviá un mensaje a:
>    smalltalking-unsubscribe@...
>
>    c.. El uso de Yahoo! Grupos está sujeto a las Condiciones del servicio
> de Yahoo!.
>
>
>
>
> 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 de Yahoo! Grupos
>
>
>
>
>
>
>
>
>

Muy buena aclaración. Y como dices ¡qué atado estamos todavía a las
tecnologías tradicionales!

Igualmente, para mi squeak, una expresión |a| no define un nombre sino un
"UndefinedObject". Las instancias de esta clase, al parecer, solo pueden
tener el valor nil, que significa que el objeto no se ha definido aún o que
el resultado de un método no tiene significado. ;-)


----- Original Message -----
From: "Alejandro F. Reimondo" <aleReimondo@...>
To: <smalltalking@...>
Sent: Tuesday, March 28, 2006 1:23 PM
Subject: Re: [objetos] Sobre los bloques | |


> Hola,
>
> Lo que comenta Esteban es correcto, pero... :-)
> permítanme aprovechar la oportunidad para recordar
> que no es correcto hablar "variables" sino de nombres.
> Le damos nombres a los objetos, y en el caso de usar
> el compilador (de clase Compiler) que viene en Smalltalk,
> es necesario declarar los nombres que se les darán a
> objetos en un contexto.
> Si mal no recuerdo hemos hablado, varias veces de este
> tema y pueden encontrar bastante detalle en esta lista.
>
> Un tema directamente relacionado con este, es la asignación,
> por ejemplo:
>    a := 12 factorial.
> indica le damos nombre "a" al objeto que se obtiene de
> enviarle el mensaje factorial al objeto de nombre (universal) "12".
> Vean que no es un asignación de variable, como, por ejemplo,
> en pascal; dónde se utiliza el mismo espacio de memoria para
> representar un dato.
> Al trabajar con objetos nos liberamos de la arquitectura de
> soporte (la memoria puede ser no direccionable, y/o el medio
> de almacenamiento puede ser no reutilizable) y por eso el
> contenido de un objeto es menos relevante que su nombre.
> Fijense el valor que tiene el nombre excede a la clase del objeto...
> Cuando decimos:
>  aPen := self surface pen.
> estamos nominando un objeto y ese nombre tiene un peso
> muy importante en el contexto (un peso tal que determina su rol)
>
> Junto a ese valor que le damos al nombre, se suma la
> importancia de la identidad del objeto, por eso, al hacer:
>   b := a.
> estamos dándole un nuevo nombre al MISMO objeto
> y no estamos copiando nada... (como seria el caso de tener
> "variables")
> Idem al hacer
>    c := b := a := d := nil.
> solo damos mas nombres al mismo objeto que se llama "nil",
> no copiamos objetos...
>
> Volviendo a la consulta de Lord ZealoN, quien seguramente
> se le ha hecho una confusión con el tema de bloques,
> creo que vale reflexionar un poco sobre la necesidad de
> las barras para "definir los nombres antes de usarlos",
> y su vínculo (en mi opinión fuerte) con el estar usando texto
> para expresar comportamiento.
> La secuencialidad del texto, mas la distracción que implica
> usar una sintaxis; nos impone reglas que no sería necesario
> adoptar en el caso de usar directamente objetos para
> expresar comportamientos; en cuyo caso, el verlo es
> suficiente para enviarle un mensaje, y no es necesario
> nominarlo explícitamente.
>
> En este punto (y algunos mas) es donde el ambiente padece
> aún hoy, +30años después, falta de avances; debidos quizás
> a esa pesada herencia con los lenguajes de programación.
> Como el llamar "variables de instancia" a los nombres
> de las partes de un objeto...
> O clases a las especies...
>
> Llevará mas de 30 años el poder desprendernos de esas
> marcas históricas?
> Es sorprendente cómo con una lectura un poco crítica,
> se pueden ver los límites culturales que se auto impusieron
> los diseñadores de Smalltalk; y es sorprendente como hoy
> en día se quedan mudos cuando uno se los nombra :-)
> Si, si... no podemos pedirle que cambien a quienes han
> ya hecho mucho, pero porque no presentar ideas nuevas
> a la gente nueva?
>
> hasta pronto,
> Ale.
>
>
>
>
> ----- Original Message -----
> From: "Esteban A. Maringolo" <eMaringolo@...>
> To: <smalltalking@...>
> Sent: Tuesday, March 28, 2006 11:54 AM
> Subject: Re: [objetos] Sobre los bloques | |
>
>
>> Lord ZealoN escribió:
>> > Estoy leyéndome el fantástico libro de Diego, pero no me ha quedado
>> > claro el tgema de los bloques
>>
>> > | size |
>> > size := self basicSize.
>> > ^self
>> > replaceBytesOf: (ByteArray new: size)
>> > from: 1 to: size startingAt: 1.
>>
>> > El | size |  que es? sería equivalente a declarar variables por
>> > ejemplo?
>>
>> Lo contenido entre | | no es un bloque, sino que es parte de la
>> pequeña sintaxis de Smalltalk, se utiliza para declarar variables
>> temporales en un contexto.
>>
>> En el caso de los métodos son temporales a la ejecución de dicho
>> método, por lo que cuando el método retorna, los objetos
>> referenciados por la variable quedan a disposición del garbage
>> collector.
>>
>> En el caso de bloques tenes dos tipos de variables, las de
>> argumentos de evaluación, y las temporales al bloque.
>>
>> Por ej:
>>
>> 1 to: 10 do: [:index | Transcript display: index; cr ]
>>
>> En este caso, :index es la declaración de una variable temporal del
>> bloque, pero a nivel argumento.
>>
>>
>> 1 to: 10 do: [:index |
>> | esPar |
>> esPar := index even.
>> Transcript
>> display: index;
>> space;
>> display: esPar;
>> cr
>> ]
>>
>> En este ultimo ejemplo, :index es una variable de argumento y esPar
>> es una variable temporal del bloque.
>>
>> Saludos.
>>
>> --
>> Esteban.
>>
>>
>>
>> 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 de Yahoo! Grupos
>>
>>
>>
>>
>>
>>
>>
>
>
>
> 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 de Yahoo! Grupos
>
>
>
>
>
>
>
>
>

Hola,

>   No se si tiene que ver con esto pero,
> hace nada estaba pensando en donde
> reside el comportamiento de una instancia
> de un objeto .

Das por seguro que "el comportamiento" es un objeto...
Estas seguro que ese planteo es correcto?

Según ese planteo un objeto sería
      (sus partes + su comportamiento)
   que serían mas partes...
   lo que es incorrecto a mi entender,
  pues indica que hay que trabajar más sobre
  el concepto de objeto como unidad/identidad
  y no como adición de elementos de una
  maquina (datos que son procesados).

>   Ya que cuando uno instancia un objeto y lo
> inspecciona no encuentra mas que los nombres
> de los objetos que este conoce y nada que lo
> lleve al comportamiento del mismo.

Eso se resuelve muy fácil... subclasificá el inspector
  para que cumpla funcionalidad de browser específico
  y esta resuelta tu inquietud...
en la práctica.
Pero no queda resuelta la que yo te planteé :-)
  Es el comportamiento un objeto?
  Porque?

>   El comportamiento queda en la clase y los
> objetos instancias acceden al mismo de
> alguna manera ???

Si, en la implemantación tradicional de un Smalltalk así ocurre.
La máquina virtual, en la resolución del envío de un mensaje
  ejecuta dos operadores básicos:
     1.- lookup
     2.- evaluate
El lookup produce un método a activar para resolver el mensaje
  que ha impactado en un objeto.
El evaluate ejecuta el método.
Se pueden presentar inconvenientes en la resolución de ambos
  operadores y está en el dominio de la máquina virtual (en el
  caso de las VMs mas usadas) la resolución de éstos problemas.

En algunos smalltalks ocurre que los métodos de un objeto,
  pueden estar (algunos) en otros lugares... quedando así la
  posibilidad de que un objeto en particular entienda mas mensajes
  que lo que especifica su clase, o que tenga métodos distintos a
  los signados por su clase.
Esto da lugar a ambientes con capacidades extendidas para sus objetos.

Volviendo al tema de comportamiento esUn: Objeto...
Para los smalltalks de hoy, todo el carácter reflexivo de los objetos
  del ambiente esta expresado en objetos :-(
Y por esta razón, el comportamiento frente a la recepción
  de un mensaje está resuelto con instancias de CompiledMethod.
Es decir, el modelo de comportamiento no solo esta resuelto
  con objetos sino que además, el comportamiento esta
  modelado como "método" (es decir, responde a un plan).
Un aforma de ver la problemática muy tradicional, que
  es aceptable, en términos de poder realizar de forma
  técnica la implementación de un ambiente en las arquitecturas
  actuales; pero que, creoyo, no tiene mas sustento que ese.

hasta pronto,
Ale.





----- Original Message -----
From: "kikote gregoris" <kikogregoris@...>
To: <smalltalking@...>
Sent: Tuesday, March 28, 2006 5:08 PM
Subject: Re: [objetos] Sobre los bloques | |


> hola
>
>   No se si tiene que ver con esto pero, hace nada estaba pensando en donde
reside el comportamiento de una instancia de un objeto .
>
>   Ya que cuando uno instancia un objeto y lo inspecciona no encuentra mas
que los nombres de los objetos que este conoce y nada que lo lleve al
comportamiento del mismo.
>   El comportamiento queda en la clase y los objetos instancias acceden al
mismo de alguna manera ???
>
>   saludos kiko
>
>
> __________________________________________________
> Correo Yahoo!
> Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
> ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

Sebastián,
Mi intensión (con las líneas siguientes) no es ser molesto,
  sino dar lugar a algún diálogo usando estos temas,
  como motivantes a reflexiones relacionadas con
  nuestros objetivos.... no me maldigas por usar unas
  palabras de tus párrafos, me parecieron buenas para
  acotar: [*]

>Es muy usado con el patrón de diseño
> model-view-controller,

MVC es un framework, no un patrón (hace un tiempo
  hablamos bastante de las diferencias, si alguien
  quiere podríamos repetir el diálogo, ya que la
  otra vez, creo que fue enriquecedor).
Por otro lado un patrón, no puede usarse;
  sino solamente instanciarse.

>se los mande a algún singleton del modelo

Por la misma razón uno no podría enviarle mensajes
  a un singleton... ya que singleton es un patrón :-)
  (y no un objeto concreto).

Esto lo digo con ganas de motivarnos a pensar
  (y hablar, si desean) sobre los elementos abstractos,
  su utilidad real...

con buena onda,
Ale.
[*] puse este prologo para evitar una mala impresión,
  cosa que casi siempre ocurre cuando uno objeta
  detalles sobre párrafos de los que no se espera
  comentarios.



----- Original Message -----
From: "Sebastián Gurin" <sgurin@...>
To: <smalltalking@...>
Sent: Tuesday, March 28, 2006 2:50 PM
Subject: [objetos] Re: [OT] Patron Command


Hola. Te tiro un ejemplo de uno de los casos más comunes del patrón de
diseño command.

Con el patrón sommand se trata de encapsular una orden (por ejemplo,
(cambiarColor, objeto1, rojo)) en un objeto. Casi siempre se realiza
construyendo una gerarquía de comandos (clases). Es muy usado con el patrón
de diseño model-view-controller, en el cual lo primero que queremos es hacer
que las capas model (dominio, modelo lógico del problema/programa) y view
(presentación/interacción con el usuario) sean independientes. En este caso
se estila a que el controller interprete las acciones/eventos del usuario,
instancie comandos (objetos que representan órdenes) y se los mande a algún
singleton del modelo para que este efectúe los cambios en el modelo.


   -----Mensaje original-----
   De: smalltalking@...
[mailto:smalltalking@...]En nombre de leonardo stortoni
   Enviado el: Lunes, 27 de Marzo de 2006 10:36 a.m.
   Para: smalltalking@...
   Asunto: [objetos] [OT] Patron Command


   Que tal a todos :

    No se si es el lugar apropiado pero bueno , queria saber si alguien me
puede dar una mano con el patron command , estuve viendo en el libro de
gamma y la verdad que no entiendo bien el ejemplo , alguien tendria por
casualidad un ejemplito en el que se vea claramente el por que usar este
patron!!!!!!!!.

   PD  alguein tiene en formato electronico el libro "head first design
pattern" me han dicho que es muy bueno y facil de entender.

   Saludos.
   __________________________________________________
   Correo Yahoo!
   Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
   ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

   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 de Yahoo! Grupos

     a.. Para visitar el sitio web del grupo, andá a:
     http://ar.groups.yahoo.com/group/smalltalking/

     b.. Para cancelar tu suscripción a este grupo, enviá un mensaje a:
     smalltalking-unsubscribe@...

     c.. El uso de Yahoo! Grupos está sujeto a las Condiciones del servicio
de Yahoo!.

Kiko,

kikote gregoris escribió:
> hola
>
> No se si tiene que ver con esto pero, hace nada estaba pensando en
> donde reside el comportamiento de una instancia de un objeto .
>
> Ya que cuando uno instancia un objeto y lo insp ecciona no encuentra
> mas que los nombres de los objetos que este conoce y nada que lo lleve
> al comportamiento del mismo.
> El comportamiento queda en la clase y los objetos instancias acceden
> al mismo de alguna manera ???
>
> saludos kiko

Los objetos pueden acceder a su comportamiento mediante su methodDictionary.

Por ejemplo, evaluá, MyClass methodDictionary y obtendrás un diccionario
cuyas claves son los selectores de los mensajes que entiende este objeto
y como values vas a tener los compiledMethods, que son objetos que
conocen el comportamiento asociado a dicho selector entre otras cosas.
Algo MUY POWER en VS (y creo que sólo en VS) es que ese comportamiento
no necesariamente es común a todas las instancias de una clase, es
decir, podés tener una instancia que posea distinto comportamiento que
las demás! ;-)

Saludos, Guillermo

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

Hola Giusseppe,

En Smalltalk, las variables locales a un método se declaran encerrando
su nombre entre barras.

P/ej. |size|

Saludos,

Francisco

El mar, 28-03-2006 a las 13:39 +0200, Lord ZealoN escribió:
> Estoy leyéndome el fantástico libro de Diego, pero no me ha quedado
> claro el tgema de los bloques
>
> Por ejemplo,
>
> asByteArray
>  "Answer a <ByteArray> containing the Unicode representation of the
> characters of the
>  receiver."
>
>  | size |
>  size := self basicSize.
>  ^self
> 	 replaceBytesOf: (ByteArray new: size)
> 	 from: 1 to: size startingAt: 1.
>
>
> El | size |  que es? sería equivalente a declarar variables por ejemplo?



__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

GS> Peroooo.... No dijiste que tenías problemas con bloques? En el ejemplo
GS> que pasás no hay ningún bloque!

Porque fué un pequeño error de definición. Lo que intenté explicar fue
lo que recordaba porque no tenía el libro delante.

Más o menos creo que voy entendiéndolo. El problema es, que como bien
dices Alejandro, yo vengo de "la escuela" de Delphi, Visual Basic,
.NET etc.. y es un cambio bastante grande (aunque necesario, estoy
cansado de lo mismo).

Yo estoy acostumbrado a, por poner un ejemplo,

Class UnaClase
   Variable ColorFondo
   Variable PosicionX
   Variable Posicion Y
   Metodo Load(sender)
   Metodo Close(sender)
   Metodo OnClick(sender)
   Metodo Colorear(ClaseColor Colorrecibido)

Metodo Colorear(OtraClase SuNombre, ClaseColor Colorrecibido)
begin
   SuNombre.BackGroundColor := ColorRecibido;
end

Y luego de todo. En cualquier otro metodo de otra clase por ejemplo.

    A: UnaCLase;
    A := new UnaClase;
    A.Colorear(FormularioEscondido, rojo);


Acostumbrado a este tipo de sintaxis (que no significa nada, solo era
un ejemplo) intento plasmarla en smalltalk. Al igual que el diseño de
una aplicación Y me está costando mucho.

Cuando yo quería desarrollar una aplicación en Delphi, creaba un nuevo
formulario, comenzaba a insertar botones, labels, Grid, controles de
acceso a datos y me ponía a escribir código. En el mismo instante que
se me ocurría una idea sabía como enfocar el "problema" (lo que tenía
en mi mente) y convertirlo en el lenguaje que entendiese el
compilador, pero en cambio, con smalltalk, no tengo todas esas
facilidades (que a lo mejor son muchas más, pero distintas) a las que
yo estaba acostumbrado, y es a lo que intento acostumbrarme.

En fin, poco a poco. Si fuese tan fácil, no sería ningún reto.

Un saludo.

P.D.: Alejandro, me encanta cómo te has explicado. Lo entendí todo a
la perfección
--

::Mi blog::
http://blog.lordzealon.com

Hola,

>Entonces que entendemos como bloque?
La palabra "bloque" es una denominación que se le daba
  a los contextos que tenían lugar dentro de un contexto
  de método.
Se denomina contexto a un conjunto de objetos (solo hay
  objetos. ok?) que están colaborando de forma orgánica
  para el cumplimiento de un objetivo.
[podríamos hablar con mas detalle, si les interesa]
La activación de un método (causado por la recepción
  de un mensaje por parte de un objeto,llamado el "objeto
  receptor / receiver") se corresponde con la creación de
  un contexto (implícito) denominado contexto de método.
El contexto actual en un instante dado, en varios Smalltalk,
  puede accederse por medio del nombre "thisContext".

Por que usamos la palabra "bloque" ? y a que denomina?
Es un resabio arcaico, de los que comentaba en el otro email...
  y por lo general es usado por personas que no hacen
  distinción clara entre código y método... ni contexto...
Digo resabio arcaico, pues se denominó "bloque" a las
  partes entre paréntesis (u otra sintaxis) de los lenguajes tradicionales,
  por ejemplo, la acción a evaluar en un IF si se da la premisa
  declarativa de dicho IF.
Así es como llamamos bloque (aún hoy :-( ) al texto que encerramos
  entre corchetes [ ... ] y que determinará la instanciación de un
  contexto cuando se "ejecute dicho código".

>Pero, ese trozo de código, iría dentro de un método no?

No es correcto referirnos a "código"... es mas fácil (y correcto)
  si ves te referís solo a objetos.
No usamos "código" en Smalltalk, así como no usamos "variables"...
Si las usáramos tendríamos una clase que las modela.
Si encontrás una clase Code o Variable, seguramente es parte
  de una herramienta de asistencia y es periférica...

> Y a eso lo llamamos bloque? (madre mía que lío)

Si, creo que el lío se produce porque a menudo en la bibliografía,
  los autores son imprecisos e incluso incorrectos. En muchos casos
  es evidente además que lo hacen adrede, pensando que así
  están ayudando a que se "entienda a trabajar con objetos".
Los resultados son muestra fiel que el efecto es el contrario,
  y que en muchos casos la falta de precisión imposibilita a quien
  esta aprendiendo el tener una idea clara de cómo pensar y
  cómo trabajar en un ambiente.
En la practica ese es un precio que todo aquel que empieza
  debe pagar, y razón por la que hay tantosmalos entendidos
  y malos conceptos formados sobre Smalltalk (y T.O. en general)
La gratuidad y el fácil acceso a material didáctico
  empeora la situación, es decir, el aprendizaje es mucho
  mas costoso.

hasta pronto,
Ale.




----- Original Message -----
From: "Lord ZealoN" <lordzealon@...>
To: <smalltalking@...>
Sent: Tuesday, March 28, 2006 12:54 PM
Subject: Re: [objetos] Sobre los bloques | |


Más o menos me va quedando más claro, pero hay algo con lo que me he liado

>  Lo contenido entre | | no es un bloque, sino que es parte de la
>  pequeña sintaxis de Smalltalk, se utiliza para declarar variables
>  temporales en un contexto.

Entonces que entendemos como bloque?

>  En el caso de los métodos son temporales a la ejecución de dicho
>  método, por lo que cuando el método retorna, los objetos
>  referenciados por la variable quedan a disposición del garbage
>  collector.
>
>  En el caso de bloques tenes dos tipos de variables, las de
>  argumentos de evaluación, y las temporales al bloque.
>
>  Por ej:
>
>  1 to: 10 do: [:index | Transcript display: index; cr ]
>
>  En este caso, :index es la declaración de una variable temporal del
>  bloque, pero a nivel argumento.
>
>
>  1 to: 10 do: [:index |
>        | esPar |
>        esPar := index even.
>        Transcript
>              display: index;
>              space;
>              display: esPar;
>              cr
>        ]
>
>  En este ultimo ejemplo, :index es una variable de argumento y esPar
>  es una variable temporal del bloque.
>
>  Saludos.
>
>  --
>  Esteban.
>

Pero, ese trozo de código, iría dentro de un método no? Y a eso lo
llamamos bloque? (madre mía que lío)

--

::Mi blog::
http://blog.lordzealon.com


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 de Yahoo! Grupos

Hola,

Lo que comenta Esteban es correcto, pero... :-)
permítanme aprovechar la oportunidad para recordar
  que no es correcto hablar "variables" sino de nombres.
Le damos nombres a los objetos, y en el caso de usar
  el compilador (de clase Compiler) que viene en Smalltalk,
  es necesario declarar los nombres que se les darán a
  objetos en un contexto.
Si mal no recuerdo hemos hablado, varias veces de este
  tema y pueden encontrar bastante detalle en esta lista.

Un tema directamente relacionado con este, es la asignación,
  por ejemplo:
     a := 12 factorial.
  indica le damos nombre "a" al objeto que se obtiene de
  enviarle el mensaje factorial al objeto de nombre (universal) "12".
Vean que no es un asignación de variable, como, por ejemplo,
  en pascal; dónde se utiliza el mismo espacio de memoria para
  representar un dato.
Al trabajar con objetos nos liberamos de la arquitectura de
  soporte (la memoria puede ser no direccionable, y/o el medio
  de almacenamiento puede ser no reutilizable) y por eso el
  contenido de un objeto es menos relevante que su nombre.
Fijense el valor que tiene el nombre excede a la clase del objeto...
Cuando decimos:
   aPen := self surface pen.
estamos nominando un objeto y ese nombre tiene un peso
  muy importante en el contexto (un peso tal que determina su rol)

Junto a ese valor que le damos al nombre, se suma la
  importancia de la identidad del objeto, por eso, al hacer:
    b := a.
  estamos dándole un nuevo nombre al MISMO objeto
  y no estamos copiando nada... (como seria el caso de tener
  "variables")
Idem al hacer
     c := b := a := d := nil.
  solo damos mas nombres al mismo objeto que se llama "nil",
  no copiamos objetos...

Volviendo a la consulta de Lord ZealoN, quien seguramente
  se le ha hecho una confusión con el tema de bloques,
  creo que vale reflexionar un poco sobre la necesidad de
  las barras para "definir los nombres antes de usarlos",
  y su vínculo (en mi opinión fuerte) con el estar usando texto
  para expresar comportamiento.
La secuencialidad del texto, mas la distracción que implica
  usar una sintaxis; nos impone reglas que no sería necesario
  adoptar en el caso de usar directamente objetos para
  expresar comportamientos; en cuyo caso, el verlo es
  suficiente para enviarle un mensaje, y no es necesario
  nominarlo explícitamente.

En este punto (y algunos mas) es donde el ambiente padece
  aún hoy, +30años después, falta de avances; debidos quizás
  a esa pesada herencia con los lenguajes de programación.
Como el llamar "variables de instancia" a los nombres
  de las partes de un objeto...
O clases a las especies...

Llevará mas de 30 años el poder desprendernos de esas
  marcas históricas?
Es sorprendente cómo con una lectura un poco crítica,
  se pueden ver los límites culturales que se auto impusieron
  los diseñadores de Smalltalk; y es sorprendente como hoy
  en día se quedan mudos cuando uno se los nombra :-)
Si, si... no podemos pedirle que cambien a quienes han
  ya hecho mucho, pero porque no presentar ideas nuevas
  a la gente nueva?

hasta pronto,
Ale.




----- Original Message -----
From: "Esteban A. Maringolo" <eMaringolo@...>
To: <smalltalking@...>
Sent: Tuesday, March 28, 2006 11:54 AM
Subject: Re: [objetos] Sobre los bloques | |


> Lord ZealoN escribió:
> > Estoy leyéndome el fantástico libro de Diego, pero no me ha quedado
> > claro el tgema de los bloques
>
> > | size |
> > size := self basicSize.
> > ^self
> > replaceBytesOf: (ByteArray new: size)
> > from: 1 to: size startingAt: 1.
>
> > El | size |  que es? sería equivalente a declarar variables por ejemplo?
>
> Lo contenido entre | | no es un bloque, sino que es parte de la
> pequeña sintaxis de Smalltalk, se utiliza para declarar variables
> temporales en un contexto.
>
> En el caso de los métodos son temporales a la ejecución de dicho
> método, por lo que cuando el método retorna, los objetos
> referenciados por la variable quedan a disposición del garbage
> collector.
>
> En el caso de bloques tenes dos tipos de variables, las de
> argumentos de evaluación, y las temporales al bloque.
>
> Por ej:
>
> 1 to: 10 do: [:index | Transcript display: index; cr ]
>
> En este caso, :index es la declaración de una variable temporal del
> bloque, pero a nivel argumento.
>
>
> 1 to: 10 do: [:index |
> | esPar |
> esPar := index even.
> Transcript
> display: index;
> space;
> display: esPar;
> cr
> ]
>
> En este ultimo ejemplo, :index es una variable de argumento y esPar
> es una variable temporal del bloque.
>
> Saludos.
>
> --
> Esteban.
>
>
>
> 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 de Yahoo! Grupos
>
>
>
>
>
>
>

Lord ZealoN escribió:
> asByteArray
>       "Answer a <ByteArray> containing the Unicode representation of the
> characters of the
>       receiver."
>
>       | size |
>       size := self basicSize.
>       ^self
>             replaceBytesOf: (ByteArray new: size)
>             from: 1 to: size startingAt: 1.
>
>
> El | size |  que es? sería equivalente a declarar variables por ejemplo?

Sí, entre los | | ponés los nombres que quieras usar en el contexto del
método (análogo a variables locales).
Peroooo.... No dijiste que tenías problemas con bloques? En el ejemplo
que pasás no hay ningún bloque!
Los bloques son objetos que literalmente se definen entre [ ]. Por ejemplo:

[Object allSubclasses]

Ahora probá mandarle #value a este objeto e inspeccioná el resultado.

[:object | Transcript cr; show: object printString]

Ahora probá manarle #value: Object new al bloque anterior.

Saludos, Guillermo

Más o menos me va quedando más claro, pero hay algo con lo que me he liado

>  Lo contenido entre | | no es un bloque, sino que es parte de la
>  pequeña sintaxis de Smalltalk, se utiliza para declarar variables
>  temporales en un contexto.

Entonces que entendemos como bloque?

>  En el caso de los métodos son temporales a la ejecución de dicho
>  método, por lo que cuando el método retorna, los objetos
>  referenciados por la variable quedan a disposición del garbage
>  collector.
>
>  En el caso de bloques tenes dos tipos de variables, las de
>  argumentos de evaluación, y las temporales al bloque.
>
>  Por ej:
>
>  1 to: 10 do: [:index | Transcript display: index; cr ]
>
>  En este caso, :index es la declaración de una variable temporal del
>  bloque, pero a nivel argumento.
>
>
>  1 to: 10 do: [:index |
>        | esPar |
>        esPar := index even.
>        Transcript
>              display: index;
>              space;
>              display: esPar;
>              cr
>        ]
>
>  En este ultimo ejemplo, :index es una variable de argumento y esPar
>  es una variable temporal del bloque.
>
>  Saludos.
>
>  --
>  Esteban.
>

Pero, ese trozo de código, iría dentro de un método no? Y a eso lo
llamamos bloque? (madre mía que lío)

--

::Mi blog::
http://blog.lordzealon.com

Lord ZealoN escribió:
> Estoy leyéndome el fantástico libro de Diego, pero no me ha quedado
> claro el tgema de los bloques

>  | size |
>  size := self basicSize.
>  ^self
> 	 replaceBytesOf: (ByteArray new: size)
> 	 from: 1 to: size startingAt: 1.

> El | size |  que es? sería equivalente a declarar variables por ejemplo?

Lo contenido entre | | no es un bloque, sino que es parte de la
pequeña sintaxis de Smalltalk, se utiliza para declarar variables
temporales en un contexto.

En el caso de los métodos son temporales a la ejecución de dicho
método, por lo que cuando el método retorna, los objetos
referenciados por la variable quedan a disposición del garbage
collector.

En el caso de bloques tenes dos tipos de variables, las de
argumentos de evaluación, y las temporales al bloque.

Por ej:

1 to: 10 do: [:index | Transcript display: index; cr ]

En este caso, :index es la declaración de una variable temporal del
bloque, pero a nivel argumento.


1 to: 10 do: [:index |
	 | esPar |
	 esPar := index even.
	 Transcript
		 display: index;
		 space;
		 display: esPar;
		 cr
	 ]

En este ultimo ejemplo, :index es una variable de argumento y esPar
es una variable temporal del bloque.

Saludos.

--
Esteban.

Insisto con la consulta...


>-----Mensaje Original-----
>Desde: Diego Martín Zacarías [mailto:diego@...]
>Enviado: Lunes 20 de Marzo de 2006 03:36 PM
>Para: smalltalking@...
>Tema: [objetos] Frame de persistencia - Dolphin - Omnibase.
>
>Hola gente.
>
>Estoy tratando de utilizar el Framework de persistencia para una
>pequeña aplicación de prueba (Cursos, Materias, Alumnos, etc).
>
>
>Leyendo los e-mail históricos al respecto veo que no aparecen en el
>paquete enviado las clases SessionComposite y AtomicComposite (y sus
>derivadas).
>
>
>Bruno: ¿Podrías hacerme llegar las mismas?
>
>
>Si bien ya he leído tu explicación respecto de su finalidad y forma
>de uso, ¿podrías darme un breve ejemplo de cómo utilizar estas
>clases?
>
>
>Desde ya agradezco toda tu ayuda,
>                                                     Diego.
>
>
>
>
>
>
>
>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 de Yahoo! Grupos
>
>
>
>
>
>
>
>

Estoy leyéndome el fantástico libro de Diego, pero no me ha quedado
claro el tgema de los bloques

Por ejemplo,

asByteArray
	 "Answer a <ByteArray> containing the Unicode representation of the
characters of the
	 receiver."

	 | size |
	 size := self basicSize.
	 ^self
		 replaceBytesOf: (ByteArray new: size)
		 from: 1 to: size startingAt: 1.


El | size |  que es? sería equivalente a declarar variables por ejemplo?
--

::Mi blog::
http://blog.lordzealon.com

El lun, 27-03-2006 a las 09:30 -0300, Alejandro F. Reimondo escribió:
Buenas.
Al final me comentaron lo del método compile: y hace exactamente lo que
yo queria. Pero por otra parte con lo que me has comentado me he puesto
a investigar y también he descubierto cosas interesante... aunque para
lo que estoy haciendo ahora que es simplemente para importar unos datos
en forma de objetos a la imagen me quedo con lo del compile

Gracias por la info
Saludos


> Eduardo,
> La alternativa que te plantee (fileIn en un stream), es muy conveniente y
> simple; pero debes tener en cuenta que usa el compilador. Es decir, es
> apropiada si no tenes necesidad de alta perfomance. Con esto no quiero
> "asustarte", sino solo comentarte que es una técnica que me ha resultado
> útil en muchos casos (como ejemplo, podes ver el sistema de la simulación de
> locomotoras que esta en el sitio), en dónde la locomotora es un archivo que
> contiene válvulas, caños, etc... (todo un sistema hidroneumático) en el que
> cada válvula y estado está programado en el mismo objeto. Al levantar la
> máquina se instancia en el ambiente y la GUI le envía mensajes a elementos
> específicos, logrando que la "simulación" ejecute. La instanciación de la
> máquina incluye generación de métodos (mas de dos mil para una locomotora
> común). En esta situación (y otros sistemas que he construido) la perfomance
> usando el Compiler (o una altenrativa de scripting) es satisfactoria.
> Es una técnica que tiene la virtud de ser entendida fácilmente (si necesitas
> presentarla a otros) y es muy portable (no depende del protocolo de
> Compiler, ni de seteos que deberías hacer, o al menos tener en cuenta, si
> quisieras interactuar con Compiler).
> Si tu uso será en casos de alta exigencia o en un producto en el que no se
> puede invertir tiempo (para ganar simpleza); deberías considerar
> alternativas a compilar y en ese caso deberíamos conocer mas en detalle que
> estas intentando hacer para poderte ayudar en su planteo.
> suerte!
> Ale.
>
>
> ----- Original Message -----
> From: "Alejandro F. Reimondo" <aleReimondo@...>
> To: <smalltalking@...>
> Sent: Sunday, March 26, 2006 12:14 PM
> Subject: Re: [objetos] Añadir métodos medianteCódigo
>
>
> > Eduardo,
> > Lo más conveniente y simple es hacer fileIn desde
> >  un stream con el contenido en formato chunk.
> > Así podes crear y/o redefinir cualquier clase, método,
> >  pool, etc... o evaluar cualquier expresión.
> > Este mecanismo es una forma simple y robusta (hay
> >  referencias a esta forma en Smalltalk/80 Bits
> >  of History words of advice...) de intercambio
> >  entre ambientes (el stream puede ser un stream
> >  sobre socket, o un archivo, sobre un string...
> >  o algo que entiende muy pocos mensajes
> >  implementados por Stream).
> > hasta pronto,
> > Ale.
> >
> >
> >
> > ----- Original Message -----
> > From: "Eduardo Ferro Aldama" <eduardo.ferro@...>
> > To: "smalltalking" <smalltalking@...>
> > Sent: Saturday, March 25, 2006 9:54 PM
> > Subject: [objetos] Añadir métodos medianteCódigo
> >
> >
> > > Buenas.
> > >
> > > Estoy seguro que existe, pero me está costando encontrar ejemplos de
> > > cómo crear métodos mediante programa... es decir quier crear por código
> > > una clase, indicarle los atributos y crear algunos métodos de acceso....
> > > por ahora lo de crear la clase y los atributos ya lo he conseguido, pero
> > > lo de los métodos no y seguro que se puede.
> > >
> > > Lo estoy haciendo en Squeak...
> > >
> > > Alguien sabe de algún doc o sitio web donde pueda aprender estos
> > > temas...
> > >
> > > Gracias de antemano
> > >
> > > --
> > > Hasta otra!
> > >   Eduardo Ferro Aldama        http://www.objectcraftsmen.com/eferro/
> > >   eduardo.ferro@...
> > >   eduardo.ferro.aldama@...
> > >   eferro@...
> > >
> > >
> > >
> > > 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 de Yahoo! Grupos
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > 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 de Yahoo! Grupos
> >
> >
> >
> >
> >
> >
> >
>
>
>
> 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 de Yahoo! Grupos
>
>
>
>
>
>
--
Hasta otra!
   Eduardo Ferro Aldama        http://www.objectcraftsmen.com/eferro/
   eduardo.ferro@...
   eduardo.ferro.aldama@...
   eferro@...
--
Hasta otra!
   Eduardo Ferro Aldama        http://www.objectcraftsmen.com/eferro/
   eduardo.ferro@...
   eduardo.ferro.aldama@...
   eferro@...

El lun, 27-03-2006 a las 03:03 -0300, Hernan escribió:
Buenas...
Al final hice algo parecido a lo que comentas, mediante el compile: de
la clase que habia creado...

Por cierto que le voy a echar un vistazo inmediatamente a los dos
documentos que me comentas...

Muchas gracias por la info

Saludos

> Podría ser algo así:
>
> | methodNode compiledMethod |
> methodNode := Compiler new compile: aTextOrStream in: aClass
> notifying: nil ifFail: [^nil].
> compiledMethod := methodNode generate: #(0 0 0 0).
>
> Seguramente te va a servir el famoso "Wrappers to the Rescue"
> http://www.laputan.org/brant/brant.html y "The Hitch Hiker Guide to
> the Smalltalk Compiler" de- Vassili Bykov
> http://www.whysmalltalk.com/articles/bykov/HitchHiker.htm
>
> Espero que te sirva, saludos.
>
> ----- Original Message -----
> From: "Eduardo Ferro Aldama" <eduardo.ferro@...>
> To: "smalltalking" <smalltalking@...>
> Sent: Saturday, March 25, 2006 9:54 PM
> Subject: [objetos] Añadir métodos medianteCódigo
>
>
> > Buenas.
> >
> > Estoy seguro que existe, pero me está costando encontrar ejemplos de
> > cómo crear métodos mediante programa... es decir quier crear por
> código
> > una clase, indicarle los atributos y crear algunos métodos de
> acceso....
> > por ahora lo de crear la clase y los atributos ya lo he conseguido,
> pero
> > lo de los métodos no y seguro que se puede.
> >
> > Lo estoy haciendo en Squeak...
> >
> > Alguien sabe de algún doc o sitio web donde pueda aprender estos
> > temas...
> >
> > Gracias de antemano
>
>
>
> __________________________________________________
> Correo Yahoo!
> Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
> ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar
>
> 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 de Yahoo! Grupos
>       * Para visitar el sitio web del grupo, andá a:
>         http://ar.groups.yahoo.com/group/smalltalking/
>
>       * Para cancelar tu suscripción a este grupo, enviá un mensaje a:
>         smalltalking-unsubscribe@...
>
>       * El uso de Yahoo! Grupos está sujeto a las Condiciones del
>         servicio de Yahoo!.
>
--
Hasta otra!
   Eduardo Ferro Aldama        http://www.objectcraftsmen.com/eferro/
   eduardo.ferro@...
   eduardo.ferro.aldama@...
   eferro@...
--
Hasta otra!
   Eduardo Ferro Aldama        http://www.objectcraftsmen.com/eferro/
   eduardo.ferro@...
   eduardo.ferro.aldama@...
   eferro@...

> 1.Como puedo hacer para agregar una caption a una
> shell cualquiera. La defino en el view composer, pero
> cuando invoco al método show para verla me aparece
> como no definida "Untitled".

Creaste un Presenter y luego asociaste el Shell del ViewComposer a este
presenter ?
Evalual en un workspace:
shell := Shell show.
shell view caption: 'JEJEJJE XXXXX'.

> 2.Como hago para poder concatenar dos string en uno
> sola.

newString := 'hola ', 'como te va'. " concatenas con la coma , "

> 3.Como hago para mostrar un valor como predefinido en
> un combo box. Especifico el modelo (una Ordered
> Collection) pero como hago para que uno de los objetos
> aparezca como predefinido en la pantalla.

lp := ListPresenter showOn: #(1 2 8 9 6 7) asOrderedCollection.
lp selection: 6.
"si es un objeto complejo se hace igual"

> 4. Como hago para manejar gráficos estadísticos,
> necesito saber si hay alguna clase q lo haga y si es
> posible me gustaría ver un ejemplo.
>
En DX6 trae para hacer graficos. http://www.alchemetrics.org/
Esta hecho en DX6.

> 5. Existe alguna clase que maneje ecuaciones
> diferenciales. Tuve q cargar "manualmente", un mensaje q lo soportará
> mediante un método numérico, me gustaría saber si existe alguna en el
> enorme ambiente que viene en la imagen, para poder obtener resultados
> mas exactos.
>

Hay un package para Dolphin pero no me acuerdo si maneja ecuaciones
diferenciales.

Saludos Bruno

Hola Mariano.

> 1.Como puedo hacer para agregar una caption a una
> shell cualquiera. La defino en el view composer, pero
> cuando invoco al método show para verla me aparece
> como no definida "Untitled".

No se porque no ves el caption correcto. Lo unico que se me ocurre es que la
View donde lo definiste no sea la 'default view' de ese shell. ¿Que hiciste
exactamente para crear ese Shell?

>   2.Como hago para poder concatenar dos string en uno
> sola.

Si queres obtener una coleccion que sea la concatencacion de otras 2, podes
usar el mensaje #,

unString, otroString

>   3.Como hago para mostrar un valor como predefinido en
> un combo box. Especifico el modelo (una Ordered
> Collection) pero como hago para que uno de los objetos
> aparezca como predefinido en la pantalla.

Si estas usando un ListPresenter, entonces podes hacer

aListPresenter model: (ListModel on: aCollection).
aListPresenter selection: anObject.    "aCollection includes: anObject"

Si estas usando un ChoicePresenter podes hacer

aChoicePresenter choices: aCollection.
aChoicePresenter model: anObject.    "aCollection includes: anObject"

> 4. Como hago para manejar gráficos estadísticos,
> necesito saber si hay alguna clase q lo haga y si es
> posible me gustaría ver un ejemplo.

Por lo que pude leer, varias personas suelen usar un control active x que
muestre charts. El mas popular parece ser TeeChart:
http://www.steema.com/

Si alguien conoce otras manera de mostrar los mismos (o mejores o mas
lindos) charts que TeeChart, me sumo al pedido de informacion.

> 5. Existe alguna clase que maneje ecuaciones
> diferenciales. Tuve q cargar "manualmente", un mensaje q lo soportará
mediante un método numérico, me gustaría saber si existe alguna en el enorme
ambiente que viene en la imagen, para poder obtener resultados mas exactos.

Aunque existe al menos un package con varios algoritmos numericos, no
conozco ninguno que resuelva ecuaciones diferenciales.
Si alguien conoce alguno para Dolphin o algun otro dialecto, me sumo al
pedido de informacion

saludos
martin

Hace unos dias escrivi a la lista una serie de 5 dudas sobre Dolphin q me quedaron despues de experimentar, tal ves no sean muy basicas pero me siguen cuasando dolor de cabezas. 
   
1.Como puedo hacer para agregar una caption a una
shell cualquiera. La defino en el view composer, pero
cuando invoco al método show para verla me aparece
como no definida "Untitled".

2.Como hago para poder concatenar dos string en uno
sola.

 

3.Como hago para mostrar un valor como predefinido en
un combo box. Especifico el modelo (una Ordered
Collection) pero como hago para que uno de los objetos
aparezca como predefinido en la pantalla.

4. Como hago para manejar gráficos estadísticos,
necesito saber si hay alguna clase q lo haga y si es
posible me gustaría ver un ejemplo.

5. Existe alguna clase que maneje ecuaciones
diferenciales. Tuve q cargar "manualmente", un mensaje q lo soportará mediante un método numérico, me gustaría saber si existe alguna en el enorme ambiente que viene en la imagen, para poder obtener resultados mas exactos.

 

Espero tener mas suerte q la ultima vez. Y esperando sus respuestas.

 

Mariano

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

leonardo stortoni escribió:
> Que tal a todos :
>
>  No se si es el lugar apropiado pero bueno , queria saber si alguien me
> puede dar una mano con el patron command , estuve viendo en el libro de
> gamma y la verdad que no entiendo bien el ejemplo , alguien tendria por
> casualidad un ejemplito en el que se vea claramente el por que usar este
> patron!!!!!!!!.

Dolphin utiliza el patrón Command para todo lo que es menúes y
botones de acción.

Mirá por Command, CommandQuery, #queryCommand: y algún otro que no
recuerdo.

Saludos.

Mariano

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

Eduardo,
La alternativa que te plantee (fileIn en un stream), es muy conveniente y
simple; pero debes tener en cuenta que usa el compilador. Es decir, es
apropiada si no tenes necesidad de alta perfomance. Con esto no quiero
"asustarte", sino solo comentarte que es una técnica que me ha resultado
útil en muchos casos (como ejemplo, podes ver el sistema de la simulación de
locomotoras que esta en el sitio), en dónde la locomotora es un archivo que
contiene válvulas, caños, etc... (todo un sistema hidroneumático) en el que
cada válvula y estado está programado en el mismo objeto. Al levantar la
máquina se instancia en el ambiente y la GUI le envía mensajes a elementos
específicos, logrando que la "simulación" ejecute. La instanciación de la
máquina incluye generación de métodos (mas de dos mil para una locomotora
común). En esta situación (y otros sistemas que he construido) la perfomance
usando el Compiler (o una altenrativa de scripting) es satisfactoria.
Es una técnica que tiene la virtud de ser entendida fácilmente (si necesitas
presentarla a otros) y es muy portable (no depende del protocolo de
Compiler, ni de seteos que deberías hacer, o al menos tener en cuenta, si
quisieras interactuar con Compiler).
Si tu uso será en casos de alta exigencia o en un producto en el que no se
puede invertir tiempo (para ganar simpleza); deberías considerar
alternativas a compilar y en ese caso deberíamos conocer mas en detalle que
estas intentando hacer para poderte ayudar en su planteo.
suerte!
Ale.


----- Original Message -----
From: "Alejandro F. Reimondo" <aleReimondo@...>
To: <smalltalking@...>
Sent: Sunday, March 26, 2006 12:14 PM
Subject: Re: [objetos] Añadir métodos medianteCódigo


> Eduardo,
> Lo más conveniente y simple es hacer fileIn desde
>  un stream con el contenido en formato chunk.
> Así podes crear y/o redefinir cualquier clase, método,
>  pool, etc... o evaluar cualquier expresión.
> Este mecanismo es una forma simple y robusta (hay
>  referencias a esta forma en Smalltalk/80 Bits
>  of History words of advice...) de intercambio
>  entre ambientes (el stream puede ser un stream
>  sobre socket, o un archivo, sobre un string...
>  o algo que entiende muy pocos mensajes
>  implementados por Stream).
> hasta pronto,
> Ale.
>
>
>
> ----- Original Message -----
> From: "Eduardo Ferro Aldama" <eduardo.ferro@...>
> To: "smalltalking" <smalltalking@...>
> Sent: Saturday, March 25, 2006 9:54 PM
> Subject: [objetos] Añadir métodos medianteCódigo
>
>
> > Buenas.
> >
> > Estoy seguro que existe, pero me está costando encontrar ejemplos de
> > cómo crear métodos mediante programa... es decir quier crear por código
> > una clase, indicarle los atributos y crear algunos métodos de acceso....
> > por ahora lo de crear la clase y los atributos ya lo he conseguido, pero
> > lo de los métodos no y seguro que se puede.
> >
> > Lo estoy haciendo en Squeak...
> >
> > Alguien sabe de algún doc o sitio web donde pueda aprender estos
> > temas...
> >
> > Gracias de antemano
> >
> > --
> > Hasta otra!
> >   Eduardo Ferro Aldama        http://www.objectcraftsmen.com/eferro/
> >   eduardo.ferro@...
> >   eduardo.ferro.aldama@...
> >   eferro@...
> >
> >
> >
> > 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 de Yahoo! Grupos
> >
> >
> >
> >
> >
> >
> >
>
>
>
> 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 de Yahoo! Grupos
>
>
>
>
>
>
>

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

Eduardo,
Lo más conveniente y simple es hacer fileIn desde
  un stream con el contenido en formato chunk.
Así podes crear y/o redefinir cualquier clase, método,
  pool, etc... o evaluar cualquier expresión.
Este mecanismo es una forma simple y robusta (hay
  referencias a esta forma en Smalltalk/80 Bits
  of History words of advice...) de intercambio
  entre ambientes (el stream puede ser un stream
  sobre socket, o un archivo, sobre un string...
  o algo que entiende muy pocos mensajes
  implementados por Stream).
hasta pronto,
Ale.



----- Original Message -----
From: "Eduardo Ferro Aldama" <eduardo.ferro@...>
To: "smalltalking" <smalltalking@...>
Sent: Saturday, March 25, 2006 9:54 PM
Subject: [objetos] Añadir métodos medianteCódigo


> Buenas.
>
> Estoy seguro que existe, pero me está costando encontrar ejemplos de
> cómo crear métodos mediante programa... es decir quier crear por código
> una clase, indicarle los atributos y crear algunos métodos de acceso....
> por ahora lo de crear la clase y los atributos ya lo he conseguido, pero
> lo de los métodos no y seguro que se puede.
>
> Lo estoy haciendo en Squeak...
>
> Alguien sabe de algún doc o sitio web donde pueda aprender estos
> temas...
>
> Gracias de antemano
>
> --
> Hasta otra!
>   Eduardo Ferro Aldama        http://www.objectcraftsmen.com/eferro/
>   eduardo.ferro@...
>   eduardo.ferro.aldama@...
>   eferro@...
>
>
>
> 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 de Yahoo! Grupos
>
>
>
>
>
>
>