Hola kiko,

>   Estuve preguntando en un foro de Games sobre Game Scripting,
> la verdad es que todabia no me queda claro de que va el tema.
>   Aqui se me recomendó hacer un Wrapper en C para interactuar
> con Engines C++ desde ST.
>   Me preguntaba si es la mejor alternativa
> o es posible usar game Scripting desde ST.

Si es posible desde C, es posible desde Smalltalk.

>   Hacer un Wrapper es mejor que game Scripting ??

El hacer un wrapper, te permite acceder a un a API,
generalmente diseñada para ser usada por desarrolladores.
El scripting tiene como destino, usuarios; que
generalmente manejan elementos a un mayor nivel
de abstracción y de manera mas instantánea.

En mi opinión, en ambos casos tenes un acceso
eficiente a una librería; la ventaja de elegir un mecanismo
frente al otro dependerá de cuánto desees involucrarte
con la implementación subyacente y de cuanto
esfuerzo requiera implementar la conexión (frente a lo
que te expone).

suerte,
Ale.


----- Original Message -----
From: "kikote gregoris" <kikogregoris@...>
To: <smalltalking@...>
Sent: Friday, July 28, 2006 11:27 AM
Subject: [objetos] Game Scripting y ST


> Hola gente
>
>   Estuve preguntando en un foro de Games sobre Game Scripting, la verdad
es que todabia no me queda claro de que va el tema.
>   Aqui se me recomendó hacer un Wrapper en C para interactuar con Engines
C++ desde ST.
>   Me preguntaba si es la mejor alternativa o es posible usar game
Scripting desde ST.
>   El Nebula Device 2 tiene un sistema de Scripting que estuve mirando pero
que no entendí mucho.
>   Busque en la web articulos, tutorial sobre el tema pero encontré muy
poco, alguien tiene material sobre el tema ??.
>   Hacer un Wrapper es mejor que game Scripting ??
>
>
>   saludos kiko
>
>
>
> ---------------------------------
>  Preguntá. Respondé. Descubrí.
>  Todo lo que querías saber, y lo que ni imaginabas,
>  está en Yahoo! Respuestas (Beta).
>  Probalo ya!

Hola,

>   En cuanto a este tema, ya no dependo del tamaño del buffer.
> Es que el problema era en realidad que no tenía que haber un
> xml -almacenado en el campo tipo text de una MySql db-
> de ese tamaño.

Que feo! me hiciste recordar que los tipos de datos aún existen!

^1 abrazo
Ale.


----- Original Message -----
From: "Felipe Zak" <zak_felipe@...>
To: <smalltalking@...>
Sent: Monday, July 31, 2006 1:11 PM
Subject: Re: [objetos] FFI Squeak -ODBC client


> Alex,
>   sí, ya había mirado en
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcsqldescribecol.asp
la documentación.
>
>   El objetivo del mail era doble:
>   1- avisar que el buffer de comunicación entre cliente y servidor - para
esa implementación de un cliente ODBC
(http://map.squeak.org/package/ba5582d8-4e50-417c-abd1-07dcd5c4d7b2)- estaba
acotado a 32K-1, que es un buen tamaño en general.
>
>   2- saber si alguien tenía otro cliente ODBC para no tener que hacer
modificacíones.
>
>   En cuanto a este tema, ya no dependo del tamaño del buffer. Es que el
problema era en realidad que no tenía que haber un xml -almacenado en el
campo tipo text de una MySql db- de ese tamaño.
>
>   gracias,
>   un abrazo,
>   Felipe
> "Alejandro F. Reimondo" <aleReimondo@...> escribió:
>   Hola Felipe,
> Te contesto, sin haber visto la implementación de la que hablas...
> Me extraña que en la implementación de la interfáz exista
> una limitación que no está presente en la base...
> El motivo de esta limitación, podría ser que el autor usó la
> interfáz en una plataforma mas condicionada que la que
> estás usando (con una dbase o driver mas condicionado).
> Yo intentaría hacerme d ela documentación de la API
> que estas usando y ver allí sus limitaciones.
> Seguramente después de eso vas a saber como modificarla
> para tus necesidades y que condicionantes esto te generaría.
> Contanos como te va con esto...
> Ale.
>
> ----- Original Message -----
> From: "Felipe Zak" <zak_felipe@...>
> To: <smalltalking@...>
> Sent: Friday, July 28, 2006 1:33 PM
> Subject: [objetos] FFI Squeak -ODBC client
>
>
> > Estoy usando FFI Squeak -ODBC.
> >
> >   El tema es que tengo campos en la base de datos que son tipo TEXT en
> > MySQL, y superan los 8192 para #BUFFERSIZE que viene por default en el
> > pool dictionary de ODBCConstants (en ODBCColumn).
> >
> >   Descubro que puedo settear #BUFFERSIZE hasta 32767, es decir 32K-1.
> > Si pongo un valor mayor o igual a 32768 me da un S1090 -Invalid string
or
> buffer length.
> >
> >   Por otro lado en: ODBCLibrary>>sqlDescribeCol: statementHandle
> > columnNumber: columnCount columnName: columnName bufferLength:
> > bufferLength nameLength: nameLength dataType: dataType columnSize:
> > columnSize decimalDigits: decimalDigits nullable: nullable
> >
> >   <cdecl: short 'SQLDescribeCol' (SQLHSTMT short void* short
> > SQLSmallInteger* SQLSmallInteger* SQLUInteger* SQLSmallInteger*
> > SQLSmallInteger*)>
> >
> >   el parámetro del bufferLength es un short, que si viene con signo
> > puede almacenar desde -32768 hasta 32767...
> >
> >   si quiero cambiar el tipo de ese parámetro debería cambiar el
> > entry point en la library... recompilar la library...
> >
> >   El objetivo es ampliar el buffer de comunicación entre el cliente y el
> servidor.
> >
> >   tips ?, comentarios ?,
> >
> >   muchas gracias,
> > saludos,
> > Felipe
> >
>
>
>

Hola,

>   En cuanto a este tema, ya no dependo del tamaño del buffer.
> Es que el problema era en realidad que no tenía que haber un
> xml -almacenado en el campo tipo text de una MySql db-
> de ese tamaño.

Que feo! me hiciste recordar que los tipos de datos aún existen!

^1 abrazo
Ale.


----- Original Message -----
From: "Felipe Zak" <zak_felipe@...>
To: <smalltalking@...>
Sent: Monday, July 31, 2006 1:11 PM
Subject: Re: [objetos] FFI Squeak -ODBC client


> Alex,
>   sí, ya había mirado en
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcsq\
ldescribecol.asp
la documentación.
>
>   El objetivo del mail era doble:
>   1- avisar que el buffer de comunicación entre cliente y servidor - para
esa implementación de un cliente ODBC
(http://map.squeak.org/package/ba5582d8-4e50-417c-abd1-07dcd5c4d7b2)- estaba
acotado a 32K-1, que es un buen tamaño en general.
>
>   2- saber si alguien tenía otro cliente ODBC para no tener que hacer
modificacíones.
>
>   En cuanto a este tema, ya no dependo del tamaño del buffer. Es que el
problema era en realidad que no tenía que haber un xml -almacenado en el
campo tipo text de una MySql db- de ese tamaño.
>
>   gracias,
>   un abrazo,
>   Felipe
> "Alejandro F. Reimondo" <aleReimondo@...> escribió:
>   Hola Felipe,
> Te contesto, sin haber visto la implementación de la que hablas...
> Me extraña que en la implementación de la interfáz exista
> una limitación que no está presente en la base...
> El motivo de esta limitación, podría ser que el autor usó la
> interfáz en una plataforma mas condicionada que la que
> estás usando (con una dbase o driver mas condicionado).
> Yo intentaría hacerme d ela documentación de la API
> que estas usando y ver allí sus limitaciones.
> Seguramente después de eso vas a saber como modificarla
> para tus necesidades y que condicionantes esto te generaría.
> Contanos como te va con esto...
> Ale.
>
> ----- Original Message -----
> From: "Felipe Zak" <zak_felipe@...>
> To: <smalltalking@...>
> Sent: Friday, July 28, 2006 1:33 PM
> Subject: [objetos] FFI Squeak -ODBC client
>
>
> > Estoy usando FFI Squeak -ODBC.
> >
> >   El tema es que tengo campos en la base de datos que son tipo TEXT en
> > MySQL, y superan los 8192 para #BUFFERSIZE que viene por default en el
> > pool dictionary de ODBCConstants (en ODBCColumn).
> >
> >   Descubro que puedo settear #BUFFERSIZE hasta 32767, es decir 32K-1.
> > Si pongo un valor mayor o igual a 32768 me da un S1090 -Invalid string
or
> buffer length.
> >
> >   Por otro lado en: ODBCLibrary>>sqlDescribeCol: statementHandle
> > columnNumber: columnCount columnName: columnName bufferLength:
> > bufferLength nameLength: nameLength dataType: dataType columnSize:
> > columnSize decimalDigits: decimalDigits nullable: nullable
> >
> >   <cdecl: short 'SQLDescribeCol' (SQLHSTMT short void* short
> > SQLSmallInteger* SQLSmallInteger* SQLUInteger* SQLSmallInteger*
> > SQLSmallInteger*)>
> >
> >   el parámetro del bufferLength es un short, que si viene con signo
> > puede almacenar desde -32768 hasta 32767...
> >
> >   si quiero cambiar el tipo de ese parámetro debería cambiar el
> > entry point en la library... recompilar la library...
> >
> >   El objetivo es ampliar el buffer de comunicación entre el cliente y el
> servidor.
> >
> >   tips ?, comentarios ?,
> >
> >   muchas gracias,
> > saludos,
> > Felipe
> >
>
>
>

Hola Felipe,
Te contesto, sin haber visto la implementación de la que hablas...
Me extraña que en la implementación de la interfáz exista
una limitación que no está presente en la base...
El motivo de esta limitación, podría ser que el autor usó la
interfáz en una plataforma mas condicionada que la que
estás usando (con una dbase o driver mas condicionado).
Yo intentaría hacerme d ela documentación de la API
que estas usando y ver allí sus limitaciones.
Seguramente después de eso vas a saber como modificarla
para tus necesidades y que condicionantes esto te generaría.
Contanos como te va con esto...
Ale.

----- Original Message -----
From: "Felipe Zak" <zak_felipe@...>
To: <smalltalking@...>
Sent: Friday, July 28, 2006 1:33 PM
Subject: [objetos] FFI Squeak -ODBC client


> Estoy usando FFI Squeak -ODBC.
>
>   El tema es que tengo campos en la base de datos que son tipo TEXT en
> MySQL, y superan los 8192 para #BUFFERSIZE que viene por default en el
> pool dictionary de ODBCConstants (en ODBCColumn).
>
>   Descubro que puedo settear #BUFFERSIZE hasta 32767, es decir 32K-1.
> Si pongo un valor mayor o igual a 32768 me da un S1090 -Invalid string or
buffer length.
>
>   Por otro lado en: ODBCLibrary>>sqlDescribeCol: statementHandle
> columnNumber: columnCount columnName: columnName bufferLength:
> bufferLength nameLength: nameLength dataType: dataType columnSize:
> columnSize decimalDigits: decimalDigits nullable: nullable
>
>   <cdecl: short 'SQLDescribeCol' (SQLHSTMT short void* short
> SQLSmallInteger* SQLSmallInteger* SQLUInteger* SQLSmallInteger*
> SQLSmallInteger*)>
>
>   el parámetro del bufferLength es un short, que si viene con signo
> puede almacenar desde -32768 hasta 32767...
>
>   si quiero cambiar el tipo de ese parámetro debería cambiar el
> entry point en la library... recompilar la library...
>
>   El objetivo es ampliar el buffer de comunicación entre el cliente y el
servidor.
>
>   tips ?, comentarios ?,
>
>   muchas gracias,
> saludos,
> Felipe
>

Fuente: Management en salud

En el foro de Genesis3D seguro saben cual es. :-)
Según lo que se, el VFS permite acceder a contenido
  zipeado (en un .pak); según entiendo, desde "afuera"
  del engine no debería haber diferencia entre usar uno u otro.
Ale.

----- Original Message -----
From: "kikote gregoris" <kikogregoris@...>
To: <smalltalking@...>
Sent: Friday, July 28, 2006 11:21 AM
Subject: [objetos] RE:Genesis(geVFile_Open??)


> Hola ALe
>
>   Esta es la respuesta  del foro:
>
>  geVFile_OpenNewFileSystem() will open a file system and geVFile_Open()
will open a file in the file system.
>
> When using the a DOS file system they do work the same but when using a
virtual file system you will notice a difference.
>
> Lo que no entiendo es cual es la diferencia entre DOS file system y
Virtual file System,  tenes idea de cual es la diferencia.
>
> saludos kiko
>
>
> ---------------------------------
>  Preguntá. Respondé. Descubrí.
>  Todo lo que querías saber, y lo que ni imaginabas,
>  está en Yahoo! Respuestas (Beta).
>  Probalo ya!

Hola Felipe,
Te contesto, sin haber visto la implementación de la que hablas...
Me extraña que en la implementación de la interfáz exista
  una limitación que no está presente en la base...
El motivo de esta limitación, podría ser que el autor usó la
  interfáz en una plataforma mas condicionada que la que
  estás usando (con una dbase o driver mas condicionado).
Yo intentaría hacerme d ela documentación de la API
  que estas usando y ver allí sus limitaciones.
Seguramente después de eso vas a saber como modificarla
  para tus necesidades y que condicionantes esto te generaría.
Contanos como te va con esto...
Ale.

----- Original Message -----
From: "Felipe Zak" <zak_felipe@...>
To: <smalltalking@...>
Sent: Friday, July 28, 2006 1:33 PM
Subject: [objetos] FFI Squeak -ODBC client


> Estoy usando FFI Squeak -ODBC.
>
>   El tema es que tengo campos en la base de datos que son tipo TEXT en
> MySQL, y superan los 8192 para #BUFFERSIZE que viene por default en el
> pool dictionary de ODBCConstants (en ODBCColumn).
>
>   Descubro que puedo settear #BUFFERSIZE hasta 32767, es decir 32K-1.
> Si pongo un valor mayor o igual a 32768 me da un S1090 -Invalid string or
buffer length.
>
>   Por otro lado en: ODBCLibrary>>sqlDescribeCol: statementHandle
> columnNumber: columnCount columnName: columnName bufferLength:
> bufferLength nameLength: nameLength dataType: dataType columnSize:
> columnSize decimalDigits: decimalDigits nullable: nullable
>
>   <cdecl: short 'SQLDescribeCol' (SQLHSTMT short void* short
> SQLSmallInteger* SQLSmallInteger* SQLUInteger* SQLSmallInteger*
> SQLSmallInteger*)>
>
>   el parámetro del bufferLength es un short, que si viene con signo
> puede almacenar desde -32768 hasta 32767...
>
>   si quiero cambiar el tipo de ese parámetro debería cambiar el
> entry point en la library... recompilar la library...
>
>   El objetivo es ampliar el buffer de comunicación entre el cliente y el
servidor.
>
>   tips ?, comentarios ?,
>
>   muchas gracias,
> saludos,
> Felipe
>

Hola kiko,

>   Estuve preguntando en un foro de Games sobre Game Scripting,
> la verdad es que todabia no me queda claro de que va el tema.
>   Aqui se me recomendó hacer un Wrapper en C para interactuar
> con Engines C++ desde ST.
>   Me preguntaba si es la mejor alternativa
> o es posible usar game Scripting desde ST.

Si es posible desde C, es posible desde Smalltalk.

>   Hacer un Wrapper es mejor que game Scripting ??

El hacer un wrapper, te permite acceder a un a API,
  generalmente diseñada para ser usada por desarrolladores.
El scripting tiene como destino, usuarios; que
  generalmente manejan elementos a un mayor nivel
  de abstracción y de manera mas instantánea.

En mi opinión, en ambos casos tenes un acceso
  eficiente a una librería; la ventaja de elegir un mecanismo
  frente al otro dependerá de cuánto desees involucrarte
  con la implementación subyacente y de cuanto
  esfuerzo requiera implementar la conexión (frente a lo
  que te expone).

suerte,
Ale.


----- Original Message -----
From: "kikote gregoris" <kikogregoris@...>
To: <smalltalking@...>
Sent: Friday, July 28, 2006 11:27 AM
Subject: [objetos] Game Scripting y ST


> Hola gente
>
>   Estuve preguntando en un foro de Games sobre Game Scripting, la verdad
es que todabia no me queda claro de que va el tema.
>   Aqui se me recomendó hacer un Wrapper en C para interactuar con Engines
C++ desde ST.
>   Me preguntaba si es la mejor alternativa o es posible usar game
Scripting desde ST.
>   El Nebula Device 2 tiene un sistema de Scripting que estuve mirando pero
que no entendí mucho.
>   Busque en la web articulos, tutorial sobre el tema pero encontré muy
poco, alguien tiene material sobre el tema ??.
>   Hacer un Wrapper es mejor que game Scripting ??
>
>
>   saludos kiko
>
>
>
> ---------------------------------
>  Preguntá. Respondé. Descubrí.
>  Todo lo que querías saber, y lo que ni imaginabas,
>  está en Yahoo! Respuestas (Beta).
>  Probalo ya!

> Alejandro y Chiara,

Hola !

> El thread tiene cosas interesantes (a favor y en contra de
> los NameSpaces)... pero debo decir que en líneas generales
> me encuentro mas de acuerdo con Chiara... :)
>
> Porque?  Porque los NameSpaces, mas allá de un montón de
> pros&cons, me *simplifican* ciertas cosas... principalmente
> el tener que pensar nombres (y todos sabemos que bautizar
> objetos no es algo trivial - mas bien fundamental).

Correcto, elegir nombres es algo de fundamental;
  y por eso debe tratarse con cuidado el tema
  y no ahorrar allí.
Concuerdo en que si no sabemos/podemos sacar
  provecho de la actividad de diálogo necesaria para
  generar el consenso de la nominación de objetos,
  se torna inútil el invertir en ello. Y por esa razón,
  esquivar "el bulto" (formando espacios estancos de
  nombres) es una opción válida; aunque en mi opinión,
  solo se logra dilatar la inversión.
En el caso de proyectos formulados como juegos finitos [*]
  (proyectos formulados y realizados de forma tradicional)
  creo que es conveniente y suficiente el formar espacios
  para evitar (por medio de encapsulamiento) el contacto
  orgánico entre partes del sistema. Aquí no hablamos de
  esas situaciones o de las posibilidades y ventajas de
  trabajar con Smalltalk en este tipo de abordaje para
  el desarrollo de sistemas.

Si pensamos en el desarrollo de sistemas que sean
  orgánicos, y formulado como juegos infinitos[*],
  el desafío pasa por el aprovechamiento de las
  energías que se requieren para el unir las partes;
  no por las ventajas que dá el separarlas :-)
Es decir, el desafío es el trabajar sobre las relaciones
  orgánicas entre las partes identidficadas (y aún no
  definidas) de un sistema, de su cinética, de su
  estabilidad. Sin tratar de evitar el acoplamiento.
Una óptica diferente a la de aislar, encapsular y
  multiplicar elementos atómicos de una maquinaria/arquitectura
  (patrones fractales de un ingenio).

[*] me refiero al planteo de juegos finitos e infinitos
  del que hablamos varias veces aquí, formulado
  hace al menos un par de años en Smalltalking,
  en las charlas en la UTN, o en Microsoft... no recuerdo..
  si me acuerdo que hay material en algunos slides en
  http://www.smalltalking.net/Events/index.htm
  y en esta lista (en yahoo).

> Otra ventaja es que me encapsula abstracciones.  Asi como
> un objeto (por medio de la definicion en su clase) me
> encapsula el nombre con que se bautizan sus colaboradores,
> un NameSpace me brinda ese mismo nivel de encapsulamiento
> pero a una escala mayor.  Y eso lo considero algo muy
> positivo.

Ventaja, en el corto plazo.
Si "el proyecto" termina antes (o el producto se rehacerá
  en un "nuevo" lenguaje la próxima vez :); todo bien,
  pues no hay largo plazo.

Cuando se busca educar al equipo de trabajo,
  estas situaciones (la polémica en la asignación
  de nombres) son muy útiles para construir
  en el equipo consenso sobre el dominio
  y generar certidumbre sobre lo que esta siendo
  cristalizado como producto del entendimiento
  grupal.

Muchas veces ocurre que el avance sobre lo
  formal es prematuro y "lo escrito" (lo diseñado
  y programado, que es lo mismo al usar Smalltalk)
  indica un avance engañoso, que no contempla
  la persistencia de dichos modelos (pues están
  sujetos a cambios, sin embargo "funcionan"
  y son correctos).

>De no tener encapsulamiento en los objetos, como
> me aseguro que la variable (ergo el nombre del colaborador)
> no esta siendo usado por alguien mas?

Cuando las personas están seguras, el sistema esta muerto.
La regulación de la incertidumbre es un instrumento
  muy valioso en al dirección de un proyecto.
Nunca debes eliminar la certidumbre (en ningún
  punto del sistema) pues allí es dónde no estarás
  preparado para soportar un cambio (que será
  inevitable, pues el sistema siempre se revela
  por dónde no estás esperándolo :)

Atención, todo lo que estoy comentando, vale trabajando
  con objetos en un ambiente.
p/f no lo extrapolen al trabajo "normal" Orientado a Objetos.

> También tiene sus contras... principalmente que es algo mas
> bien estático (como dice Alejandro) y que plantea nuevas
> complejidades (ej: importar, exportar, resolución de
> conflictos, etc) pero bueno me parece que los beneficios
> son mayores que los costos.

> Particularmente si uno intenta integrar frameworks o cargar
> varias cosas con nombres no-óptimos (y no me digan que no
> existen!)  El mundo esta lleno de código que no es de lo
> mejor, cuyos nombres son confusos y hasta errados.
>  Tomemos cualquier Smalltalk y veremos que sus abstracciones
> son erradas (o poco claras) para ciertos dominios.

Dejame disentir.
No son erradas, son de otros.
Y de otros tiempos.

No se porque a veces pensamos que las abstracciones
  son válidas siempre (fuera de todo contexto) y para
  todo sistema (hombres incluidos)...
Además, como toda implementación ya no es abstracta,
  sino que tiene un nivel de abstracción (respecto de otras)
  está sujeta (como toda instancia) a un tiempo de vida.

La persistencia de una instancia esta siempre dada por
  la estabilidad de su entorno.
Cambiar una abstracción o una implementación por otra
  en un Smalltalk no es tarea simple; ni una tarea resoluble
  con refactorización (por definición).
En teoría, uno se imagina (debí decir en la imaginación
  y no en teoría.. :) un camino apropiado para reemplazar
  una implementación por otra; pero solo después de
  hacerlo empieza a darse cuenta lo inocente que uno era
  al plantearlo.
Les aseguro lo de arriba en base a las experiencias que
  he tenido haciendo smalltalkS en dónde fuí libre de
  cambiar y reformular cualquier parte...
La estabilidad y aptitud de un ambiente se conoce una
  vez que está andando; y un cambio tiene las implicancias
  que tiene el cambio de una especie por otra.
Si una cambia... empiezan a cambiar todas :-)
No tiene analogía en la práctica a lo que ocurre al
  cambiar una clase por otra en un esquema formal,
  aunque si puede parecernos que la tiene...

>  Por
> ejemplo, digamos que estoy haciendo un sistema de
> asistencia escolar; #Class ya esta tomado por el ambiente,
> con lo cual debo recurrir a 'inventar' un nuevo nombre (ej:
> StudentClass) y que después se nos propaga a los mensajes
> (si le pido #class estoy nuevamente en conflicto con el
> ambiente, ergo tengo que definir el mensaje #studentClass;
> y todo mi sistema o modelo se ve 'contaminado' por el
> simple hecho de que hubo alguien que 'me gano de mano' en
> usar el nombre).

Porque pensas que no podes cambiar lo que está escrito?
Cambiar lo que escribió el anterior no solo es valido,
  sino que es indispensable para poder afirmar que el sistema
  evoluciona (y no solo cambia, a saltos).
Nada está escrito en piedra.
Pero si tocas Array>>#at: ... asegurate de que quede
  andando todo :-P
  sinó vas a tener varios compañeros de trabajo incómodos
  jajaja

> Esta 'contaminación de los mensajes es algo que opaca,
> desluce o hace mas críptico el código, y que podría ser
> resuelto con lo que creo haber entendido de lo que dijo
> Alejandro... y que explico acá (tanto para discutir el tema
> como para verificar que fue lo que Alejandro quiso decir -
> corregime si no lo es! :)

Si, fue una de las cosas que decía.
Creo que en el mail anterior queda mejor el punto.
Para resumirlo; es preferible "mandar un mensaje"
  como siempre.

> Hasta aquí tendríamos la situación donde un NameSpace
> decide hacer un override del mensaje #class para acomodarlo
> a *su* dominio...

Si, pero debe mantener la semántica...
  cosa que será difícil si no devuelve la clase :-)
Quizás el ejemplo sea mejorable, eligiendo un mensaje
  de un dominio mas concreto y no vital para el
  funcionamiento del ambiente.
La idea esta ok.

> En el segundo caso, dado que el sender esta definido en el
> NameSpace de Smalltalk.School, este envío debería de
> mapearse al Smalltalk.School.Enrolment>>#class
>
> La idea me parece muuuy interesante... pero muuuuuuuuy
> inmanejable (o peligrosa).  Este ejemplo es trivial (es un
> getter al fin y al cabo) y si bien puede resultar en cosas
> muy inesperadas, no cambia el estado de ningún objeto.
>
> En cuanto empiece a modificar el estado y/o relaciones
> entre objetos de esta manera puede tornarse extremadamente
> difícil de saber que va a pasar cuando envío un mensaje.

Cuando envias un mensaje... nunca sabes que va a pasar;
  y a veces no sabes todo lo que pasó luego de enviarlo.
  (la formación de un cardumen es un buen ejemplo de
  lo que comento)
  El todo es mas que la suma de las partes.

Toda idea de control que nos hagamos respecto
  de lo que pase en un sistema forma parte de una reducción
  que hacemos para podernos imaginar que lo dominamos.
En un sistema abierto en contenido y en el tiempo,
  no es muy útil fantasear con que uno produce algo
  invariante.
No hay constantes, no hay variables; hay solo nombres
  que les damos a los objetos en un contexto para focalizar
  la atención para el envío de mensajes.

> Por ejemplo, supongamos (nuevamente) un Stream que en un
> NameSpace le redefino el #next para que haga un #skip antes
> de hacer el #next (no se, solo me interesa la mitad del
> stream ;) pero me olvido de modificar el #skip:, #position
> etc... el Stream puede quedar en estados incoherentes e
> invalidos, en donde sus invariantes ya no lo son... y solo
> porque 'extendi' el #next...
>
> Alejandro, era esto (o similar) a lo que te referías??
> Si es Asi, mi comentario es que esta muy copado, pero poco
> aplicable (o mejor dicho, una capacidad muy poderosa, ergo
> peligrosa... hay que tener mucho criterio para su
> utilización provechosa).
>
> Si no era esto... podes explicar a que te referías?
> Y obvio, ignoren todo lo anterior... :P

Es algo de lo que comentaba.
Además de la aplicabilidad que tiene, es importante
  considerar la comunidad en la que se usa.
Un abordaje como este requiere de un soporte comunitario.
Por ejemplo, las colecciones siempre se usaron en Smalltalk;
  su uso y extensión fue promovido y quien usa Smalltalk
  considera  posible que una persona las use y reuse.
En Cpuspus ocurrió lo mismo pero llevó mas de diez años
  el lograr unconcenso sobre las ventajas y desventajas, etc...
En ese período quienes usaban soluciones interesantes
  eran vistos como divergentes de la media y "sorprendían".
Para lograr no sorprender, es importante tener un
  sustento practico y comunitario.
Esto es lo que se busca, lograr en Squeak con Traits (nos
  guste o no el abordaje en esa dirección).
Algo similar con NameSpaces no ocurrió aún,
  y realmente no creo que suceda (en mi opinión,
  ojalá que no :-)
Este "ojalá que no" se entiende, creo yo, cuando uno
  estudia la propuesta del ANSI Smalltalk (la usa/vive
  en la práctica) y observa como una parte importante
  de la comunidad Smalltalk se esmera por pinchar
  el globo o por hacer esfuerzos en hurgar el ombligo
  en abordajes atomicistas (traits).

> En fin, volviendo a los NameSpaces... no se, por un lado me
> gustan y por otro lado me agregan una carga previamente
> inexistente.  Particularmente si yo soy el autor de todo
> (ya que yo bautice a todos mis objetos es difícil tener
> demasiados conflictos inesperados).  Pero si estoy tratando
> de reusar frameworks de otros, no tengo control sobre sus
> abstracciones y sus nombres, con lo cual no quiero que me
> afecten y los NameSpaces me proveen ese encapsulamiento...
> y como vago que soy (soy un buen objeto - a veces) prefiero
> integrar a desarrollar (je... delegación máxima ;)
>
> Sigo intercalando algunos comentarios... mas como notas al
> margen que como temas... :)

> > Reconozco que mi punto de vista es bastante particular
> >  y poco frecuente en este tema. :-)
>
> Cierto... eso no quiere decir nada per se... el tema es
> lograr transmitirlo completamente :)

Imposible hacerlo.
Quien lo escucha o lee entiende lo que puede
  y lo que es de utilidad a su propósito. :-)

Importante es la actividad, los productos de la actividad
  son variados y muchas veces inesperados.

Durante años he asistido a cursos de facultad (varias
  veces para principiantes), a veces me han invitado a hablar
  o amablemente a discutir temas de lo que trataban
  en las materias.
La actividad de comentar como veía los temas y escuchar
  como los conocen y perciben los demás; es de mucho
  valor si uno lo sabe usar. Sin importar la cantidad de
  esas ideas que pudieran quedar en quienes las
  escucharon.

> > Los contextos, como los conocemos, son contextos de
> >  ejecución, y definidos por un espacio de tiempo en
> >  donde interactúan objetos concretos.
> >
> > El concepto de espacio de nombres es al menos
> >  "objetable". ;-)
>
> Bueno... técnicamente es cierto, el nombre es simplemente
> una 'abreviatura/apodo' al objeto, pero usualmente ese
> nombre entra en juego como nombre de mensajes...

Si, de todas maneras, la nominación de mensajes
  es realizada de forma mas indirecta que la de objetos.
La relevancia de la nominación de objetos es mucho
  mayor que la de mensajes por su importancia
  conceptual (su relación directa con el modelo
  conceptual).
El acuerdo y selección en nombre de mensajes es realizada
  de forma indirecta y pocas veces es producto de diálogos
  forjadores de consenso. Son manejados de forma mas
  relajada que para los nombres de objetos.

> pero aun
> Asi, internamente, los objetos funcionan como unidad de
> contención para sus nombres de variables de instancia...

Decir MySystemDictionary::MiClase
  es como decir:
      miObjecto.miParte
No entiendo porque se acepta un binding estático
  y el otro no (se recomienda un envío de mensaje
     miObjeto miParte
  en el ultimo caso).

> >
> > Por otro lado, el nombre es solo eso, no cumple
> >  un rol en el sistema (de objetos) y como tal es un
> >  elemento pasivo (no puede desenvolverse en el
> >  sistema objeto, lo hace en el meta-sistema).
> >
> > Ante mi POV, con la nominación alcanza, pues considero
> >  que su valor es tal para quien solo piensa en declarar
> >  un sistema (para quien busca trabajar con código/diseño
> >  y no con objetos).
>
> Esteee... el código y disenho son parte de los objetos.

Para quien piensa que declarar objetos es suficiente.

> Supongo que te estas refiriendo a un (avanzado) estado de
> un eco-sistema de objetos donde no existen nuevas
> abstracciones (solo re-combinaciones de las existentes) con
> lo cual no hay que especificar las bases.

Me refiero a sistemas construidos en base a vínculos orgánicos.
(hacer una analogía con lo ecológico no es necesario
  y da lugar a pensar en que hay en las bases un vínculo
  con lo natural)

> >
> > >>Es un hecho reciente en Smalltalk,
> > >> y en realidad (en la práctica es)  innecesario;
> > >A mi entender no es del todo así. Teóricamente si puede
> > > se innecesario ya que la posibilidad de nombres para
> > > las clases es potencialmente infinita :-).
> >
> > No, no lo decía por eso...
> > Lo decía en la practica, la Teoría...
> >  ...me aburrió hace tiempo.
> >
> > >Pero a la hora de llevarlo a la práctica poder definir
> > >tu namespace es algo que ayuda
> >
> > Si trabajas declarativamente.
> > Por ejemplo, en C++ y Java, dónde SOLO podes trabajar
> >  declarativamente -y es conveniente que solo trabajes
> >  así- es de mucho valor usar nombres compuestos.
> > Trabajando con objetos no es tan determinante el usarlos.
>
> En ambos casos estas navegando una estructura de
> referencias (violando la Ley de Demetrio)... solo que
> cuando lo haces declarativamente dejas explícito el camino
> que tomaste, mientras que si 'trabajas con objetos' el como
> lo obtuviste es impenetrable ya que fue 'puesto' ahí por el
> que manipulo los objetos... de donde lo saco??

Importa decir de dónde salió?
Decirle a quién?
(no olvides que en mi planteo es que uno
  esta para el sistema y su desarrollo, no al revés)

> > Las ventajas de usar Smalltalk incluyen el trabajar en
> >  equipos reducidos lo que hace mas fácil una dinámica
> >  orgánica en dónde las personas no divergen
> >  productivamente sino que trabajan en paralelo, sin
> >  implicar esto ultimo desperdicio de recursos por
> >  duplicaciones.
> Eso es suponiendo un escenario totalmente bajo tu control.
> A veces eso no es posible, eficiente o deseable.

Por eso es importante promover al uso de ambientes.
Para que sea posible. :-)

No es conveniente promover a que cada vez sea
  mas difícil trabajar así.
Aunque sea mas "fácil".

>  Y no
> siempre esta relacionado con el 'tamanho' del sistema.  A
> veces es un tema de competencias, divide-y-conquistaras,
> reuso, etc.  Y los NameSpaces (como dije) sirven para
> encapsular esos 'espacios de abstracciones' que cada unidad
> de desarrollo necesita.

Es correcto, en ámbitos de trabajo dónde no
  se aprovecha el estar usando un ambiente
  más allá de su potencial como un buen
  IDE + 1 buen LOO.

> >
> > > imaginate si se desarrollan X módulos de forma
> > > independiente, que tienen nombres en común como State o
> > > Type y que después se quieran unir.
> >
> > 1.- aprovecharía para sacar del equipo a quienes usen
> >     esos nombres... sacarlos por un tiempo hasta que
> >     aprendan la lección y luego seguramente se
> >     incorporarán dándole la importancia que tiene el
> >     elegir nombres.
> > 2.- si el daño "ya esta hecho", hay que poner (poca)
> >     energía para repararlo. Y mucha mas energía para
> >     educar a quienes trabajaron de esa forma.
> >
> > En otras palabras (y tratando de que lo de arriba no sea
> >  malentendido :) educar en la selección de nombres y en
> el
> >  valor que tiene la nominación de objetos (q sea
> >  consensuada) es costoso, pero importante en el caso de
> >  usar objetos.
>
> Mmm... casi Pavloviano lo tuyo... :P  Pero mas allá de los
> aspectos pedagógicos, seguís partiendo del supuesto que vos
> controlas absolutamente todo el desarrollo (al menos dentro
> de la imagen) ergo inventaste (o re-invetastes) todas las
> ruedas habidas y por haber...

No es necesario controlar todo para poder construir
  en equipo un sistema estable.
Es importante manejar la ansiedad, y aprovechar
  las incertidumbres del equipo para permitir un contexto
  de trabajo productivo.
Al segmentar el sistema en parcelas (aplicar el concepto
  de propiedad sobre el "código") y definir interfaces para
  sus nombres, se hace mas difícil controlar la incertidumbre
  y aprovechar la incertidumbre imposible (creo, pues
  nunca he visto alguien que lo aproveche trabajando
  de esa forma; por lo general se lo evita, al no poderlo
  manejar).

> En cuanto a que es 'poca' la energía, no estoy tan de
> acuerdo, ya que para garantizar que todo lo que cambiaste
> no tiene efectos colaterales es muy difícil... Por ejemplo,
> cuantas veces hemos usado el símbolo/string del nombre de
> una clase para operar sobre el?  El caso mas trivial seria
> sacar los prefijos que la falta de NameSpaces nos forzó en
> el nombre, otros seria obtener la subclase apropiada con la
> cual hay que engancharse... cierto, todas esas referencias
> podrían haber sido hechas por medio de mensajes (y métodos)
> específicos, pero bueno, la gracia de tener un meta-sistema
> es poder usarlo...

No es necesario garantizarlo.
Tenes que educar a la gente para que trabaje de forma
  responsable.
Para eso se requiere de buena educación (no alcanza una
  buena instrucción). Un ambiente sirve para eso.

> > Ahh! entonces no uses código.
> > Construí un sistema.
> Acá me perdí... para construir algo necesito los planos.

Para contruir una arquitectura necesitas los planos.
No es necesario construir un sistema como se
  construye un edificio.
Puede hacerse de otras formas.
Por ejemplo, haciendolo crecer, de forma orgánica;
  desde una semilla, día a día; sin que pase por estados
  de inestabilidad fuertes (para que no presente fragilidad,
  o mejor dicho, para que sea robusto, entensible
  y blablabla... en resumen, sea sano).

No es necesario que responda a un diseño previsto
  ni que sea correcto o perfecto.
Si es perfecto, es porque ya está muerto.

> Pueden ser mas o menos formales (ej: plano de arquitecto
> aprobado por la municipalidad, un bosquejo en una
> servilleta, o una idea mental algo borrosa).
> Desafortunadamente las computadoras son muy burocráticas...
> y quieren código!
> Y por mas avanzado que tengas tu ambiente, siempre
> necesitas el glue-code...

Pero hace +30 años se ve una tendencia
  a no pensar así :-P
Y esto permitió abordajes complementarios
  al que se daba con Pascal, luego con Modula y ADA
  y luego, algo mas recientemente con los LOOs
  de uso masivo.
Obviamente, esos abordajes no se dieron, ni se dan hoy
  en comunidades que siguen pensando en escribir código
  mas rápido (ni en los que dibujan cajitas o nubes llamadas
  componentes y objetos respectivamente).

Por esta razón tener un lugar donde podamos pensar
  distinto, es importante y lo peor que nos podemos
  hacer es hacer analogías, buscar medias tintas,
  o pensar que lo que sirve para unos es bueno/practico
  para quien hace otro abordaje.

> > Me refería a que si se ve lindo, queda...
> >  hasta que alguien "pase y lo limpie" :-(
> >  (varias veces mucho tiempo mas tarde)
> > > mi criterio es el de programación "linda" y escalable,
> > > por eso me gusta el diseño en objetos (aunque debo
> > > confesar que usaba Java :s) y en particular Smalltalk.ç
> > "linda" ? como el éxito es siempre subjetivo... :-)
> > "escalable" ? solo hay que agregar objetos, si usaste
> >  objetos no habría razón por la que no pudiera escalar.
> Cierto, el éxito es subjetivo.  La escabilidad tambien.  Y
> los objetos no hacen algo escalable por esencia.

Exacto, es consecuente de la actividad que desarrollas.

>  La
> escalabilidad se encuentra -principalmente- en el disenho,
> u en menor (pero crucial - el diablo esta en los detalles)
> en su implmentacion.

No pienso igual.
Pensar que un diseño es escalable basandose en
  su fórmula es ignorar la importancia del tiempo (de
  elaboración humano requerido para entender
  un contexto) y de lo que excede a su formula (un diseño
  como elemento abstracto no contiene todo lo requerido
  como para aseverar eficiencia en un caso concreto
  planteado a futuro).

Lo único que puede garantizar aplicabilidad a un contexto
  distinto (en el futuro) es la realización de una actividad
  que permita a un sistema alterar su contenido de forma
  estable; preservando su identidad. Cosa que no puede
  pedirse de un formalismo como un diseño (por definición).

[...corte un párrafo grande aquí...]
> > Cuantas colisiones tenes en lo que estás portando?
> > Si podes, decinos de que porcentaje de nombres
> >  colisionados estamos hablando,como para darnos
> >  una idea de la gravedad del "problema" :-)
> > Si el porcentaje es alto me sorprendería, pero
> >  indica que está afectando de forma concreta el
> >  producto y en este aspecto me gustaría hacer un
> >  estudio de los NameSpaces.
>
> La cantidad de colisiones no es importante.  Bueno si, pero
> lo mas importante es el poder aislarlo.  El 'renombrar'
> manualmente esos conflictos es una solucion temporal,
> ineficiente y poco mantenible.  Por un lado, para
> asegurarnos de haber redirigido correctamente todas las
> referencias el trabajo es muy desgastante (principalmente
> porque uno debe poder entender como funciona para saber que
> cambiaste todas las referencias, aun las dinamicas y sus
> implicancias).  Finalmente, después de haber hecho todo ese
> trabajo, lo hiciste todo dentro de una imagen y con un
> 'paquete' de objetos fuente.

Entonces no hay nada mejor que desde un cominezo
  no haber usado NameSpaces :-P

> El dia de maniana, cuando tengas que armar una nueva
> imagen, o salga una nueva version vas a tener que rehacer
> todo...

Mañana, seguro vas a releer todo.
Si no tenes tiempo siquiera de releerlo...
  ni revivirlo
  no lo portes a otro lado;
  sería irresponsable hacerlo.

hasta pronto,
Ale.


----- Original Message -----
From: "Ether Plasma" <etherplasm@...>
To: <smalltalking@...>
Sent: Wednesday, July 19, 2006 1:51 PM
Subject: Re: [objetos] Re: NameSpacs en Squeak


> Alejandro y Chiara,
>
> El thread tiene cosas interesantes (a favor y en contra de
> los NameSpaces)... pero debo decir que en lineas generales
> me encuentro mas de acuerdo con Chiara... :)
>
> Porque?  Porque los NameSpaces, mas alla de un monton de
> pros&cons, me *simplifican* ciertas cosas... principalmente
> el tener que pensar nombres (y todos sabemos que bautizar
> objetos no es algo trivial - mas bien fundamental).
>
> Otra ventaja es que me encapsula abstracciones.  Asi como
> un objeto (por medio de la definicion en su clase) me
> encapsula el nombre con que se bautizan sus colaboradores,
> un NameSpace me brinda ese mismo nivel de encapsulamiento
> pero a una escala mayor.  Y eso lo considero algo muy
> positivo.  De no tener encapsulamiento en los objetos, como
> me aseguro que la variable (ergo el nombre del colaborador)
> no esta siendo usado por alguien mas?
>
> Tambien tiene sus contras... principalmente que es algo mas
> bien estatico (como dice Alejandro) y que plantea nuevas
> complejidades (ej: importar, exportar, resolucion de
> conflictos, etc) pero bueno me parece que los beneficios
> son mayores que los costos.
>
> Particularmente si uno intenta integrar frameworks o cargar
> varias cosas con nombres no-optimos (y no me digan que no
> existen!)  El mundo esta lleno de codigo que no es de lo
> mejor, cuyos nombres son confusos y hasta errados.  Tomemos
> cualquier Smalltalk y veremos que sus abstracciones son
> erradas (o poco claras) para ciertos dominios.  Por
> ejemplo, digamos que estoy haciendo un sistema de
> asistencia escolar; #Class ya esta tomado por el ambiente,
> con lo cual debo recurrir a 'inventar' un nuevo nombre (ej:
> StudentClass) y que despues se nos propaga a los mensajes
> (si le pido #class estoy nuevamente en conflicto con el
> ambiente, ergo tengo que definir el mensaje #studentClass;
> y todo mi sistema o modelo se ve 'contaminado' por el
> simple hecho de que hubo alguien que 'me gano de mano' en
> usar el nombre).
>
> Esta 'contaminacion' de los mensajes es algo que opaca,
> desluce o hace mas criptico el codigo, y que podria ser
> resuelto con lo que creo haber entendido de lo que dijo
> Alejandro... y que explico aca (tanto para discutir el tema
> como para verificar que fue lo que Alejandro quizo decir -
> corregime si no lo es! :)
>
> --------- code [1] begin ---------
> Smalltalk.Core.Object>>class
> "Answer the object which is the receiver's class."
>
> <primitive: 111>
> self primitiveFailed
>
> Smalltalk.School.Enrolment>>class
> "Answer the School.Class for the enrolled student."
>
> ^class
> --------- code [1] end ---------
>
> Hasta aqui tendriamos la situacion donde un NameSpace
> decide hacer un override del mensaje #class para acomodarlo
> a *su* dominio...
>
> Ahora el tema seria como deberia reaccionar el ambiente
> ante un dado mensaje #class:
>
> --------- code [2] begin ---------
> Smalltalk.Core.SomeObject>>foo
> "Example extra-namespace method..."
> "The result would be an instance of Core.Behavior"
>
> ^anObject class
>
> Smalltalk.School.SomeObject>>foo
> "Example intra-namespace method..."
> "The result would be an instance of School.Class"
>
> ^anObject class
> --------- code [2] end ---------
>
> En el primer metodo, el mensaje #class esta dentro del
> Smalltalk.Core NameSpace y por lo tanto deberia mapearse
> con el comportamiento definido en ese NameSpace -
> especificamente Smalltalk.Core.Object>>#class
>
> En el segundo caso, dado que el sender esta definido en el
> NameSpace de Smalltalk.School, este envio deberia de
> mapearse al Smalltalk.School.Enrolment>>#class
>
> La idea me parece muuuy interesante... pero muuuuuuuuy
> inmanejable (o peligrosa).  Este ejemplo es trivial (es un
> getter al fin y al cabo) y si bien puede resultar en cosas
> muy inesperadas, no cambia el estado de ningun objeto.
>
> En cuanto empiece a modificar el estado y/o relaciones
> entre objetos de esta manera puede tornarse extremadamente
> dificil de saber que va a pasar cuando envio un mensaje.
> Por ejemplo, supongamos (nuevamente) un Stream que en un
> NameSpace le redefino el #next para que haga un #skip antes
> de hacer el #next (no se, solo me interesa la mitad del
> stream ;) pero me olvido de modificar el #skip:, #position
> etc... el Stream puede quedar en estados incoherentes e
> invalidos, en donde sus invariantes ya no lo son... y solo
> porque 'extendi' el #next...
>
> Alejandro, era esto (o similar) a lo que te referias??
> Si es asi, mi comentario es que esta muy copado, pero poco
> aplicable (o mejor dicho, una capacidad muy poderosa, ergo
> peligrosa... hay que tener mucho criterio para su
> utilizacion provechosa).
>
> Si no era esto... podes explicar a que te referias?
> Y obvio, ignoren todo lo anterior... :P
>
> En fin, volviendo a los NameSpaces... no se, por un lado me
> gustan y por otro lado me agregan una carga previamente
> inexistente.  Particularmente si yo soy el autor de todo
> (ya que yo bautice a todos mis objetos es dificil tener
> demasiados conflictos inesperados).  Pero si estoy tratando
> de reusar frameworks de otros, no tengo control sobre sus
> abstracciones y sus nombres, con lo cual no quiero que me
> afecten y los NameSpaces me proveen ese encapsulamiento...
> y como vago que soy (soy un buen objeto - a veces) prefiero
> integrar a desarrollar (je... delegacion maxima ;)
>
> Sigo intercalando algunos comentarios... mas como notas al
> margen que como temas... :)
>
>
>  --- "Alejandro F. Reimondo" <aleReimondo@...>
> escribió:
>
> > Hola Chiara,
> >
> > >Hola Alejandro, gracias por la respuesta y por la
> > tentativa de solución.
> > >Asimismo no comparto tu punto de vista con respecto a
> > los Namespaces.
> >
> > Reconozco que mi punto de vista es bastante particular
> >  y poco frecuente en este tema. :-)
>
> Cierto... eso no quiere decir nada per se... el tema es
> lograr transmitirlo completamente :)
>
> > > Los namespaces son valiosos para quienes entienden que
> > > es deseable aumentar la capacidad declarativa de la
> > > sintaxis de Smalltalk, para permitir declarar(de forma
> > > previa) una nominación mas específica que la dada por
> un
> > > solo nombre.
> > > Totalmente de acuerdo en este punto. El namespace te da
> > > el contexto en el que  se desenvuelve el nombre.
> >
> > A que contexto te referís?
> > Los nombres no están en el espacio de los objetos, sino
> >  en el de su "definición", por lo que no sería correcto
> >  definir un espacio de nombres por contención.
> >
> > Los contextos, como los conocemos, son contextos de
> >  ejecución, y definidos por un espacio de tiempo en
> >  donde interactúan objetos concretos.
> >
> > El concepto de espacio de nombres es al menos
> >  "objetable". ;-)
>
> Bueno... tecnicamente es cierto, el nombre es simplemente
> una 'abreviatura/apodo' al objeto, pero usualmente ese
> nombre entra en juego como nombre de mensajes... pero aun
> asi, internamente, los objetos funcionan como unidad de
> contencion para sus nombres de variables de instancia...
>
> >
> > Por otro lado, el nombre es solo eso, no cumple
> >  un rol en el sistema (de objetos) y como tal es un
> >  elemento pasivo (no puede desenvolverse en el
> >  sistema objeto, lo hace en el meta-sistema).
> >
> > Ante mi POV, con la nominación alcanza, pues considero
> >  que su valor es tal para quien solo piensa en declarar
> >  un sistema (para quien busca trabajar con código/diseño
> >  y no con objetos).
>
> Esteee... el codigo y disenho son parte de los objetos.
> Supongo que te estas refiriendo a un (avanzado) estado de
> un eco-sistema de objetos donde no existen nuevas
> abstracciones (solo re-combinaciones de las existentes) con
> lo cual no hay que especificar las bases.
> Desafortunadamente, cada vez que entramos en un nuevo
> dominio (o lo revisitamos con nuestro actual estado mental)
> las abstracciones presentes no alcanzan y nos vemos
> 'forzados' a especificar nuevas...
>
> >
> > >>Es un hecho reciente en Smalltalk,
> > >> y en realidad (en la práctica es)  innecesario;
> > >A mi entender no es del todo así. Teóricamente si puede
> > > se innecesario ya que la posibilidad de nombres para
> > > las clases es potencialmente infinita :-).
> >
> > No, no lo decía por eso...
> > Lo decía en la practica, la Teoría...
> >  ...me aburrió hace tiempo.
> >
> > >Pero a la hora de llevarlo a la práctica poder definir
> > >tu namespace es algo que ayuda
> >
> > Si trabajas declarativamente.
> > Por ejemplo, en C++ y Java, dónde SOLO podes trabajar
> >  declarativamente -y es conveniente que solo trabajes
> >  así- es de mucho valor usar nombres compuestos.
> > Trabajando con objetos no es tan determinante el usarlos.
>
> En ambos casos estas navegando una estructura de
> referencias (violando la Ley de Demetrio)... solo que
> cuando lo haces declarativamente dejas explicito el camino
> que tomaste, mientras que si 'trabajas con objetos' el como
> lo obtuviste es impenetrable ya que fue 'puesto' ahi por el
> que manipulo los objetos... de donde lo saco??
>
> (Obvio, si es que entiendo correctamente a que te referis
> con 'trabajando con objetos'... ;))
>
> >
> > > y más si se quiere hacer un desarrollo distribuido (en
> > > más de una persona :)).
> >
> > No opino igual :-)
> > Siempre es conveniente promover la interacción entre las
> >  personas y es determinante en los costos de producción a
> >  mediano y largo plazo.
> > Las ventajas de usar Smalltalk incluyen el trabajar en
> >  equipos reducidos lo que hace mas fácil una dinámica
> >  orgánica en dónde las personas no divergen
> >  productivamente sino que trabajan en paralelo, sin
> >  implicar esto ultimo desperdicio de recursos por
> >  duplicaciones.
>
> Eso es suponiendo un escenario totalmente bajo tu control.
> A veces eso no es posible, eficiente o deseable.  Y no
> siempre esta relacionado con el 'tamanho' del sistema.  A
> veces es un tema de competencias, divide-y-conquistaras,
> reuso, etc.  Y los NameSpaces (como dije) sirven para
> encapsular esos 'espacios de abstracciones' que cada unidad
> de desarrollo necesita.
>
> >
> > > imaginate si se desarrollan X módulos de forma
> > > independiente, que tienen nombres en común como State o
> > > Type y que después se quieran unir.
> >
> > 1.- aprovecharía para sacar del equipo a quienes usen
> >     esos nombres... sacarlos por un tiempo hasta que
> >     aprendan la lección y luego seguramente se
> >     incorporarán dándole la importancia que tiene el
> >     elegir nombres.
> > 2.- si el daño "ya esta hecho", hay que poner (poca)
> >     energía para repararlo. Y mucha mas energía para
> >     educar a quienes trabajaron de esa forma.
> >
> > En otras palabras (y tratando de que lo de arriba no sea
> >  malentendido :) educar en la selección de nombres y en
> el
> >  valor que tiene la nominación de objetos (q sea
> >  consensuada) es costoso, pero importante en el caso de
> >  usar objetos.
>
> Mmm... casi Pavloviano lo tuyo... :P  Pero mas alla de los
> aspectos pedagogicos, seguis partiendo del supuesto que vos
> controlas absolutamente todo el desarrollo (al menos dentro
> de la imagen) ergo inventaste (o re-invetastes) todas las
> ruedas habidas y por haber...
> En cuanto a que es 'poca' la energia, no estoy tan de
> acuerdo, ya que para garantizar que todo lo que cambiaste
> no tiene efectos colaterales es muy dificil... Por ejemplo,
> cuantas veces hemos usado el simbolo/string del nombre de
> una clase para operar sobre el?  El caso mas trivial seria
> sacar los prefijos que la falta de NameSpaces nos forzo en
> el nombre, otros seria obtener la subclase apropiada con la
> cual hay que engancharse... cierto, todas esas referencias
> podrian haber sido hechas por medio de mensajes (y metodos)
> especificos, pero bueno, la gracia de tener un meta-sistema
> es poder usarlo...
>
>
> > En los equipos dónde se trabaja declarativamente y/o no
> >  se puede dar el lujo de educar, se permite a los
> miembros
> >  del equipo trabajar aislados.
> > (una analogía, algo extrema... pero creo que vale)
> > Para reducir el delito, algunos piensan que hay que
> >  usar vidrios polarizados.
> > Otros piensan que es muy costoso.
> >
> > Con los nombres (de objetos y de mensajes) pasa algo
> > similar.
> >
> > >Obvio que se pueden modificar los nombres anteriores
> > >anteponiendo el Namespace (NamespaceClase) pero es algo
> > >que "molesta" al desarrollo y a mi entender perjudica
> > >la lectura del código, en definitica, a mi entender no
> es
> > >práctico.
> >
> > Ahh! entonces no uses código.
> > Construí un sistema.
>
> Aca me perdi... para construir algo necesito los planos.
> Pueden ser mas o menos formales (ej: plano de arquitecto
> aprobado por la municipalidad, un bosquejo en una
> servilleta, o una idea mental algo borrosa).
> Desafortunadamente las computadoras son muy burocraticas...
> y quieren codigo!
> Y por mas avanzado que tengas tu ambiente, siempre
> necesitas el glue-code...
>
> >
> > >>En comunidades mas libres, comola de Squeak, esta
> > >>presión no existe; y esa es una de las razones (creo)
> > >>por la que una utilidad que no sea necesaria en la
> > >>práctica no está presente.
> > >Me parece perfecto. Pero me gustaría que alguien hubiera
> > > solucionado este "problema" :(.
> >
> > Ante mi POV, te comentaba que,
> >  no es un problema (luego no debería haber una solución).
>
> Bueno, hay gente que destapa las botellas con casi
> cualquier cosa (cuchillos, tenedores, mesas, dientes, etc.)
> pero existe el objeto Destapador... La gente que solo sabe
> abrir las botellas con el, tiene un problema cuando no lo
> tiene y se queda con sed.  Por el otro lado, el que 'no
> tiene problema' en abrirlas con cualquier cosa, de vez en
> cuando rompe el cuello de la botella... y tambien se queda
> con sed, o come vidrio... ;)
>
> (Nota: 'Destapador' no esta calificado pero el contexto
> habla de botellas y no de inodoros... el contexto es el
> NameSpace).
>
> >
> > >>En todo Squeak se observa lo contrario a presiones
> > >> respecto del "estilo" y se valora mucho más la
> > >> estética del resultado que la forma en que está
> > >> logrado, su estabilidad e incluso su calidad.
> > >mmmm no se a que te referís acá. calidad en base a que
> > criterio?
> >
> > Me refería a que si se ve lindo, queda...
> >  hasta que alguien "pase y lo limpie" :-(
> >  (varias veces mucho tiempo mas tarde)
> >
> > > mi criterio es el de programación "linda" y escalable,
> > > por eso me gusta el diseño en objetos (aunque debo
> > > confesar que usaba Java :s) y en particular Smalltalk.ç
> >
> > "linda" ? como el éxito es siempre subjetivo... :-)
> > "escalable" ? solo hay que agregr objetos, si usaste
> >  objetos no habría razón por la que no pudiera escalar.
>
> Cierto, el exito es subjetivo.  La escabilidad tambien.  Y
> los objetos no hacen algo escalable por esencia.  La
> escalabilidad se encuentra -principalmente- en el disenho,
> u en menor (pero crucial - el diablo esta en los detalles)
> en su implmentacion.
>
> >
> > Trabajando declarativamente, si hay problemas de
> >  escalabilidad, pero casi siempre por negación de sus
> >  costos (y no previsión de la energía que lleva cambiar
> >  un sistema, mas aún cuando uno no esta EN el sistema).
> >
> > >>Por esta razón, creo que si encontrás en Squeak algo
> > >> "parecido" a NameSpaces, serán restos de algo que ha
> > >> desaparecido (luego de algunos ensayos para demostrar
> > >> su inutilidad práctica real).
> > >:-(
> >
> > Espero no te desanime lo que dije...
> >
> > >>De vez en cuando en la lista de Squeak se gravita sobre
> > >> este punto (en realidad sobre la problemática de la
> > >> nominación dinámica; que es un tema más amplio y
> > >> ambicioso).
> > >> Cuando esto ocurre aparecen al menos dos reflexiones
> > >> de forma recurrente:
> > >> 1.- tener NameSpaces solo para nombres de objetos
> > >> es una solución de corto plazo; pues en realidad lo
> > >> útil sería poder extender el concepto a los mensajes
> > >> (con lo que se complica mucho mas el tema).
> > >este....
>
> Mi 'modelo' de sobre-escritura al inicio del mail, era
> esto??
>
> > >>2.- que el naming sea estático (resuelto en durante la
> > >> compilación) es algo inútil y solo resuelve las
> > >> colisiones; es decir, no da servicio al sistema mismo,
> > >> sino solo a las personas que lo escriben (declaran);
> > >> por lo que no es un tema del sistema en si, sino de la
> > >> sintaxis en que se expresa en texto... (si el sistema
> > >> se construye con objetos, el problema desaparece, y se
> > >> transforma en un tema del pasado)
> > >No estoy de acuerdo.
>
> Para mi no es inutil.  Tiene su utilidad.  Limitada.  Pero
> no por ello deja de ser util, por mas que no sea un intento
> en reducir la complejidad y minimizar conflictos entre
> cosas que vos solo queres usar...
>
> >
> > En que parte(s)?
> > (yo tampoco estoy deacuerdo en algunas de estas, es
> >  lo que recuerdo de lo que se habló en la lista de
> > Squeak)
> >
> > >Muchos usan un argumento parecido (no es problema del
> > >"sistema") para justificar la falta de bloques en Java.
> >
> > :-) bastante inocente.
> > No puedo responder por quien diría algo así.
> > Q que se inscriba y lo ponga en esta lista,
> >  así conversamos sobre lo que piensa de los bloques.
> >
> > > ERROR! el "sistema" tendría que facilitar la
> > > programación y lograr que el programador se centre en
> > > el qué y no en el cómo.
> >
> > El sistema?
> > No tiene noción ni se entera de que hay alguien
> > (generalmente un humano?) a quien debe servir...
> > Un sistema de objetos abierto, como es un ambiente,
> >  no tiene compromiso con su creador; no es para con él;
> >  sino al revés.
> > Vos sos para el sistema.
>
> "Resistance is futile &#8212; you will be assimilated."??
>
> Si bien estoy de acuerdo con que existen sistemas
> (submundos) que 'cobran vida' mas alla de las intenciones
> originales (ej: la web) yo diria que la gran mayoria de
> sistemas dejarian de funcionar de no haber personas a su
> alrededor.  Con lo cual estaria de acuerdo...
>
> Pero, el compromiso del sistema para con su creador, si
> bien no es explicito, es implicito: en cuanto su cohorte de
> humanos que le dan soporte deciden que ya no es util,
> muere.  Por lo tanto, el compromiso existe... de mantenerse
> util.  Es incapaz de hacerlo solo, pero eso solo lo deja
> indefenso... no necesariamente amo y senhor... es un rey,
> pero que esta desnudo.
>
> >
> > Cuando construimos un sistema con objetos,
> >  decimos: "este es mi sistema"
> >  el "mi" en "mi sistema" define una relación
> >  como la que está presente en :
> >   Mi Dios, Mi Amor, etc...
> > Dónde el objeto no es para nosotros, sino al revés.
> >
> > El sistema no facilita(ni perjudica) su creación,
> >  si esta construido con objetos.
>
> Poco importa con que esta construido...
>
> >
> > Si el sistema del que hablamos es un sistema cerrado,
> >  el cual es posible (y a veces recomendable) definirlo
> >  declarativamente; entonces si se aplica lo que vos
> >  decías (dónde el sistema es el sistema usado para
> >  conceptualizarlo/modelarlo); pero en ese caso
> >  estaríamos hablando de trabajar solo Orientado a
> >  objetos y no con objetos.
> >
> > >Namespaces ayuda un poquito, mínimamente, pero
> > >ayuda.
> >
> > >>Ultima recomendación:
> > >> Te decía que los NameSpaces no son peligrosos...
> > >> Verificá bien como funciona lo que estás migrando,
> > >>  pues los mas difícil de migrar de un Smalltalk a
> > >>  otro es que hay diferencias que son sutiles y afectan
> > >>  tanto perfomance como a veces son causales de fallas
> > >>  imprevistas.
> > >Ok, lo tendré en cuenta.
> >
> > No se si desestimaste la opción de definir el NameSpace
> >  con el comportamiento de acceso...
> > Creo que es una solución "elegante" (de las lindas :)
> >  y que no te haría perder mucho tiempo.
> >
> > Cuantas colisiones tenes en lo que estás portando?
> > Si podes, decinos de que porcentaje de nombres
> >  colisionados estamos hablando,como para darnos
> >  una idea de la gravedad del "problema" :-)
> > Si el porcentaje es alto me sorprendería, pero
> >  indica que está afectando de forma concreta el
> >  producto y en este aspecto me gustaría hacer un
> >  estudio de los NameSpaces.
>
> La cantidad de colisiones no es importante.  Bueno si, pero
> lo mas importante es el poder aislarlo.  El 'renombrar'
> manualmente esos conflictos es una solucion temporal,
> ineficiente y poco mantenible.  Por un lado, para
> asegurarnos de haber redirigido correctamente todas las
> referencias el trabajo es muy desgastante (principalmente
> porque uno debe poder entender como funciona para saber que
> cambiaste todas las referencias, aun las dinamicas y sus
> implicancias).  Finalmente, despues de haber hecho todo ese
> trabajo, lo hiciste todo dentro de una imagen y con un
> 'paquete' de objetos fuente.
>
> El dia de maniana, cuando tengas que armar una nueva
> imagen, o salga una nueva version vas a tener que rehacer
> todo...
>
>
> >
> > gracias a vos!
> >
> > hasta pronto,
> > Ale.
> >
> >
> > ----- Original Message -----
> > From: "Chiara" <muralito@...>
>
> /Ether Plasm
>
>
>
>
>
> __________________________________________________
> Preguntá. Respondé. Descubrí.
> Todo lo que querías saber, y lo que ni imaginabas,
> está en Yahoo! Respuestas (Beta).
> ¡Probalo ya!
> http://www.yahoo.com.ar/respuestas
>
>
>
> 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 Chiara,

>> >Totalmente de acuerdo en este punto. El namespace te da el
>> > contexto en el que  se desenvuelve el nombre.
>> A que contexto te referís?
>> Los nombres no están en el espacio de los objetos, sino en
>> el de su "definición", por lo que no sería correcto definir
>> un espacio de nombres por contención.
>Ok, me refer´ia al contexto en el que se desenvuelve la clase,
> el contexto declarativo. EJ MyApp::State el State en el
> contexto de MyApp

Sisis, analicemos un poco MyApp::State...
O... MyContext::State (afirmar
  que una aplicación esUn contexto sería interesante,
  si pensaramos que es necesaria la
  existencia del un objeto "aplicación").

El MyContext::State define un vinculo estático el cual
  es creado declarativamente y de forma trasparente (
  yo lo llamaría oculta) y por esta razón, además de ser
  estático es determinante del funcionamiento/utilidad
  de ambos objetos (el MyContext y el State).
La situación es similar a la nominación de "colaboradores
  internos" (si hay un nombre horrible es este) de los objetos,
  en dónde los conocidos de un objeto son nominados
  estáticamente produciendo la misma situación (el
  objeto necesita a la parte, tanto como la parte al
  objeto; ... como un circulo necesita un borde).

Esta situación "difícil" se ha resuelto históricamente en
  Smalltalk por medio de la educación en el uso de mensajes.
Incluso cuando se usa una parte de un objeto, se envía
  un mensaje; y NO se discute si es rápido o no el hacerlo;
  es parte de la educación el enviar mensajes (en vez de
  usar la "variable de instancia").
Esta educación ha costado mucho en el pasado a Smalltalk.
A tal punto de ser fuertemente criticada (por quienes no
  conocían del tema) la actitud de enseñar este tipo
  de "técnicas"...
Pese a ese costo alto, el precio ya fue pagado (como
  tantas otras cosas, como el compilar dinámicamente,
  usar una VM, etc).

Decía que se ha resuelto con el envío de mensajes,
  pues si uno desea llegar a un "conocido" de un objeto,
  lo que hace es enviarle un mensaje...

En el caso de MyContext::State se rompe con esa
  actitud educativa (de enseñar a quien usa Smalltalk)
  y se presenta una fórmula declarativa (y estática)
  como una solución conveniente para una situación
  simple y concensuada históricamente.

El proponer "MyContext::State" va en contra del
  esfuerzo hecho históricamente, y tiene un olor
  característico del abandono de lo que Smalltalk
  ha sido desde que es...

Fijate que el plantear "MyContext state" (es decir,
  usar mensajes... como siempre) es tan simple
  y resoluble técnicamente, como lo es el acceso
  a instancias; evitando romper con uno de los axiomas
  principales de Smalltalk (la homogeneidad).

Para quien está acostumbrado a trabajar declarativamente
  (declarando líneas de código) da lo mismo escribir una
  cosa que otra; pues en realidad el código que escribe
  es similar al ADN del sistema y no espera otra cosa
  más que el sistema se comporte siempre así, como
  él lo dijo/diseño.

Para quienes trabajamos no solo declarativamente (es
  decir, para quienes usamos un ambiente en forma
  constructiva) la diferencia es importante, no solo porque
  nos molesta lo estático, sino porque evita seguir
  usando Smalltalk de forma educativa en esas partes
  e incluso produce heterogeneidad/ambigüedades.

Cual sería "mi planteo"...
  si hay "algo" que es el sistema/framework o como
  lo deseemos llamar, hagámoslo un objeto (en el espacio
  de los objetos, y no en el espacio de nombres
  solamente), e implementémosle los mensajes
  como lo hacemos con los demás objetos.
Para esto no es necesario cambiar ninguna sintaxis,
  solo debemos seguir haciendo lo mismo de siempre.
Y queda en el dominio de las herramientas el poner
  opciones para trabajar (o no) con estos objetos;
  tal como ocurre con la categorización de objetos (clases,
  mensajes, etc)

Entonces... no tendríamos NameSpaces, sino
  Aplicaciones, Frameworks, o lo que necesitemos
  modelar... con el contenido y comportamiento
  que requieren para ser bindeados, etc...

>>Los contextos, como los conocemos, son contextos de
>> ejecución, y definidos por un espacio de tiempo en
>> donde interactúan objetos concretos.
>Sisi,  yo dije "contexto" y vos entendiste "contexto"
> (somos objetos diferentes entendemos de forma
> diferente los mensajes; mi "contexto"
> pertenece a un contexto diferente al tuyo ;-))

Algo de lo que no hablamos aún, es de la cinética
  de los nombres.
Es común que haya una convergencia y una disección
  en el espacio de nombres; tal como la hay en el espacio
  de nombres de mensajes.

Podemos hablar de tu "contexto" y mi "contexto"
  por un tiempo como cosas distintas pues eso sirve
  para no perder las diferencias. Pero con el diálogo
  está garantida la convergencia a un "modelo acordado"
  de contexto...

La energía que se debe poner para corresponder
  esa cinética en un sistema con la que existe en las
  personas es conveniente manejarla con envío
  de mensajes y no con binding estático.
La facilidad de preservar las diferencias por más
  tiempo que el necesario es contraproducente a
  mediano plazo; y el sistema debe reflejar los avances
  en acuerdo de términos/nombres para permitir
  que refleje la actividad(/energía) que la gente
  pone en el sistema (y así realizar métricas y tracking
  de consenso).
Este tipo de tracking no es común en equipos
  que trabajan guiados por diseño previo OO y LOO
  pero es sano en el trabajo en un ambiente.
Muy poco se habla de esto en las comunidades
  de Smalltalk hoy; creo que gracias a que se promueve
  constantemente una vuelta atrás (pinchar el
  globo, para mojar "las patas" en el mar de
  los lenguajes).

>>Ante mi POV, con la nominación alcanza, pues considero
>> que su valor es tal para quien solo piensa en declarar un
>> sistema (para quien busca trabajar con código/diseño
>> y no con objetos).
>este...no entiendo tu punto de vista... para trabajar con
> objetos tenes que nombrarlos de alguna manera
> (no a los objetos, sino a sus clases), y en este
> punto a mi particularmente me ayudan los namespace.

Si nominas las clases, estas nominando objetos :-)

No es necesario nominar objetos, es necesario "focalizar"
  en el receptor de un mensaje.
La nominación es forzada al usar texto, de forma declarativa,
  como medio de expresión de un futuro envío de mensaje.
Estudios como los de PTT (programación a través del tiempo)
  y medios de expresión como morphic permiten entender
  que para instanciar comportamiento (un método)
  es solo necesario poder focalizar/distinguir a un objeto
  receptor en el instante en que vas a dispararle un mensaje.
Si luego queres repetir ese comportamiento (activar
  nuevamente ese método o contexto), la activación
  requerirá de un binding, que es meramente enumerativo
  y esto se modela en Smalltalk con el uso de instancias
  de Context (method context y context).

La no necesidad de nombres para el funcionamiento de
  un sistema de objetos, se evidencia además cuando
  hacemos un stripping de un sistema, en dónde
  es común que se elimine (si es posible) hasta los
  nombres de las clases (y otros objetos globales)
  destruyendo incluso PoolDictionaries y sobreviviendo
  solamente las asociaciones (en algunos casos solo
  el #value y no la #key).

> Poner un prefijo a cada nombre o hacer nombres
> de clases quilometricos no es algo que me guste y me
>parezca "cómodo"

Entonces no usas expresiones como:

     ^self surface extent

en dónde toda la frase es solo un nombre largo :-)

Aunque no nos guste es mejor que escribir:

     this.surface.extent

pues es mejor enviar mensajes....

Esto no es objetable en Java ni en Cpuspus,
  pues es una practica aceptada; pero en Smalltalk
  se ha invertido mucho en educación como para
  tirar por la borda lo que nos distingue (la
  valoración de la utilidad de la delegación)

>>Si trabajas declarativamente.
>> Por ejemplo, en C++ y Java, dónde SOLO podes trabajar
>> declarativamente -y es conveniente que solo trabajes así-
>> es de mucho valor usar nombres compuestos.
>> Trabajando con objetos no es tan determinante el usarlos.
>Puede ser, pero a mi entender ayuda (al desarrollador no
> al sistema.

A corto plazo si, a mediano plazo es objetable y depende
  tanto de cómo se trabaje, como de los objetivos que
  se tengan (por ejemplo si se valora más el producto que
  la actividad, es apropiado).
A largo plazo no ayuda a las personas, pues los inhibe
  de usar los sentidos, solo usan su "visión (de futuro)"
  y el oportunismo de abordar de forma abstracta el
  mayor numero de dominios posibles para una
  formalización.
Es decir, a largo plazo (se puede ver) que se crean
  "admiradores de lo abstracto" y personas que
  acostumbran a pensar y proyectar, antes que construir.
Nuevamente (espero no ser pesado, al repetirlo),
  esto es apropiado, para un soporte que
  no da para más que para eso, como los LOOs y las
  arquitecturas que se montan basadas en modelos
  abstractos, pero no es el caso de un ambiente
  en dónde podemos ambicionar más que una
  escritura cómoda (pues lo que se escribe no es tanto
  como para limitar la producción).

>Pero en definitiva el que desarrolla es el desarrollador
> no? si me haces un sistema que diseñe e implemente
> sistemas, ahí si te voy a dar la razón que los
> namespaces son totalmente inútiles, pero mientras
> el que tenga que desarrollar el sistema tenga que ser
> yo, voy a quere namespaces (tal vez sea
> un poco terco pero soy así :-)) )

Si, todo bien!!!
Pero... entonces porque no queres pagar ese precio
  (muy pequeño) de implementartelo en Squeak (esta
  todo ahí como para con muy poco esfuerzo hacerlo).
Es más.. creo que en un aépoca, en la versión 3.8? (no recuerdo)
  había aun abordaje de est etema, cuando deseaban
  implementar ágilmente packages de linking dinámico
  cosa que no paso a mayores que tímidos ensayos,
  que, creo que no llegaron a más, justamente por la
  no necesidad imperiosa de tenerlos. En una comunidad
  libre como la de Squeak, creo que pueden pasar años
  hasta que se instala algo no necesario; y loa casos en los
  que se hace una instalación no necesaria corresponde
  con políticas internas y grupos que quieren dirigir "la
  evolución" jajaja! (como es el caso de los abordajes
  atomicistas para el comportamiento)

>>Las ventajas de usar Smalltalk incluyen el trabajar en equipos
>> reducidos lo que hace mas fácil una dinámica orgánica en
>> dónde las personas no divergen productivamente sino que trabajan
>> en paralelo, sin implicar esto ultimo desperdicio de recursos por
>> duplicaciones.
>aja, pero también se pueden evitar duplicaciones utilizando namespaces :-)

Evitar el conflicto es perder oportunidad de diálogo
  y avance concensuado (en el caso de desarrollos en conjunto).
Es apropiado el no tener conflictos cuando uno no pude
  tener al lado a la persona que usa el mismo nombre;
  en el caso que es posible tener a esa persona; el evitar
  el conflicto es contraproducente.

La cinética de los nombres que un equipo usa es
  un recurso de seguimiento (traking de avance real
  en el entendimiento de un dominio).
Se que somos muy pocos los que hacemos este tipo
  de seguimientos (conozco solo dos personas
  que lo usan como yo). A mi me resulta muy provechoso
  el tracking de nombres y considero el encapsulamiento
  de los nombres una forma de permitir la falta de consenso
  y el no compromiso con las partes del sistema que
  uno no "desarrolla".

>> imaginate si se desarrollan X módulos de forma
>> > independiente, que tienen nombres en común como State o Type
>> > y que después se quieran unir.
>> 1.- aprovecharía para sacar del equipo a quienes usen esos nombres...
>>    sacarlos por un tiempo hasta que aprendan la lección y luego
>>    seguramente se incorporarán dándole la importancia que tiene el
>>    elegir nombres.
>La importancia la tiene porque no tenes namesapaces.
> Es como tener un path relativo o un path absoluto.

Creo que justo arriba puse el porqué lo decía.
Y que así se entenderá la importancia que le doy
  y también porque no se le da importancia comúnmente,
  como vos decías.

>>2.- si el daño "ya esta hecho", hay que poner (poca) energía para
>>     repararlo. Y mucha mas energía para educar a quienes trabajaron
>>    de esa forma.
>De acuerdo con la filosofía, no se si se aplica acá.
> Tal vez este "mal educado" ;-)

jajaja! quizás "no educado" :-P
Comúnmente se instruye, no se alcanza a educar.
Se instruye en las universidades a modelar y diseñar...

[...snip...]
>Ok, igualmente no es solo por el trabajo aislado o no
> (siempre es bueno tener buena interacción) .
> Pero supongamos que el día de mañana tenes alguna
> extensión, o lo necesitas integrar en otro sistema,
> con namespaces te ahorras colisiones y algunos
> dolores de cabeza (seguramente los menores y
> mas simples, pero te los ahorras, entre pagar
> 0.1 y no pagar, prefiero no pagar ;-))

No es así.
Siempre pagas, tarde o temprano.
Me podrás dar seguramente varios ejemplos para
  demostrar que no es como yo digo, pero es cuestión
  de actitud.
Prefiero tener la actitud de decir: "aquí me puedo
  sorprender y encontrar algo imprevisto", por eso lo
  voy a releer con los pies puestos aquí y ahora.

>>>Obvio que se pueden modificar los nombres anteriores
>>>anteponiendo el Namespace (NamespaceClase) pero es algo
>>> que "molesta" al desarrollo y a mi entender perjudica la lectura
>>> del código, en definitica, a mi entender no es práctico.
>> Ahh! entonces no uses código.
>> Construí un sistema.
>Aja... y como hago eso?

Trabajando no-declarativamente.
No preocupandote por escribir el código.
Escribir un buen código, es como preocuparse en sintetizar
  un buen código genético.
No es que "sea malo" el refinar los genes...
Solo es estúpido, denota un desconocimiento
  de los limites de la genética.
El tratar a cada instancia como un "sistema vivo" (con
  identidad única y en ejercicio ESTE instante) plantea
  un desafío distinto, en dónde se valora el disfrute
  de la actividad por sobre el resultado.
La diferencia es la misma que existe entre la proteómica
  y la genética. (explico un poco mas la diferencia. no? :)
La genética trata las características heredables de
  un individuo (instancia esUn: clase).
Así según los "papeles" de la familia de un toro, podemos
  saber que ese toro será un buen padrillo...
Y que conviene comprarlo.
Pero NO podremos saber si ese toro puede
  morir mañana por estar enfermo o no servirá por
  haber tenido una enfermedad de chico!
Allí es el dominio de la proteómica...
la proteómica estudia es estado del toro AHORA
  en base a su cinética de proteínas (que genera esa
  máquina hoy).
No alcanza con su código para saber si un sistema
  está bien. Es necesario saber que esté bien, que sea estable...

Y allí es dónde se une nuestro abordaje sobre sistemas!
Esa es una de las cosas de valor en nuestro
  trabajo constructivo del sistema.
El valor está en el compromiso con su estabilidad;
  cosa que no puede ser garantida formalmente,
  por más metaarquitectura que pongamos (u objetos
  que agreguemos).

>>"linda" ? como el éxito es siempre subjetivo... :-)
>> "escalable" ? solo hay que agregr objetos, si usaste objetos
>> no habría razón por la que no pudiera escalar.
>NO no no. No por el solo hecho de usar objetos las
> cosas escalan.

Eso dicen los libros.
En la práctica, si fuiste bien educado en objetos sabes
  como hacer escalar un sistema. No porque sea algo
  que aprendiste de leer un texto/libro/paper; sino
  porque ya lo hiciste varias veces.

Siempre partimos de una semilla y la hacemos
  crecer hasta que nos dicen "basta!"

> Las cosas escalan por una
> metodología usada.

Si, si queres intentá "d"escribirlo como un método.
Yo prefiero no hacerlo :-)
Pues creo que no es necesario el formular
  un método formal del trabajo no-formal :)

> Siempre se puede hacer
> moco en todo paradigma y todo lenguaje.

Es común, en los libros y en las universidades
  que se eche la culpa a la gente y no al método :-)
Y que ninguno de los que ´se vió sorprendido por
  esas "faltas de escalabilidad" esté allí para dialogar
  sobre las condiciones en que se dió...
Me ha pasado varias veces, escuchar argumentos
  de proyectos inconclusos o insatisfactorios usando
  objetos y pobres reflexiones sobre las situaciones
  que alentaron esos resultados. Esto se dió mas
  veces en ámbitos universitarios que en compañías
  o empresas que utilizan la TO.
  (quizás fué porque en estos últimos si lo decían
  tenían que pagar mi tiempo de consultoría :-P )

>>Espero no te desanime lo que dije...
>para nada. Cuando tenga mas tiempo y realmente
> los necesite, los implementare y listo.
> El poder "estar en el sistema" me deja moldearlo a mi
> necesidad particular :-).

Exacto!

>>Cuando construimos un sistema con objetos,
>> decimos: "este es mi sistema"
>> el "mi" en "mi sistema" define una relación
>> como la que está presente en :
>>   Mi Dios, Mi Amor, etc...
>> Dónde el objeto no es para nosotros, sino al revés.
>No se que relación tendrás vos con "tus" sistemas,
> pero yo intento construirlos para facilitarme el trabajo
> futuro, para que me resuelvan la problemática actual,
> para que se adapte a mis necesidades y no al revés

Lo que buscas está garantido.
Prácticamente no conozco persona que diga
  no haberlo logrado.
  (lo digo en serio, no es joda!)

Si uno pregunta... todos son exitosos.
El cambio es ocasional y guiado por las modas.
Un buen día aparece un nuevo lenguaje, y ya todos
  empiezan a cambiarse las camisetas y a reescribir
  todo :-P

>> Cuantas colisiones tenes en lo que estás portando?
>> Si podes, decinos de que porcentaje de nombres
>> colisionados estamos hablando,como para darnos
>> una idea de la gravedad del "problema" :-)
>Jeje, para serte sincero, no es mucho, y se soluciona
> sin namespaces; pero igualmente me interesaría la
> idea de tener namespaces.

Si.
Te lo preguntaba, porque es una de las cosas que
  es valioso evaluar para analizar costo/beneficio.
Fijate en tu ambiente (con NameSpaces :)
  cuantas colisiones tenes... y ponderá el tiempo
  que llevaría cambiar a mano los nombres...
  frente al tiempo que lleva conformar (en equipo)
  que nombre debe usarse.
La actividad de consenso es mucho mas costosa,
  y eso denota que estás haciendo algo en tu gente
  cuando la forzas a concensuar un nombre en un
  determinado contexto.


ojo! no deseo hacer que pienses distinto, solo deseo
  hablar y explorar un poco mas allá de lo que planteaba
  tu pedido.

  un cordial saludo,
Ale.




----- Original Message -----
From: "Chiara" <muralito@...>
To: <smalltalking@...>
Sent: Wednesday, July 19, 2006 2:16 PM
Subject: Re: [objetos] Re: NameSpacs en Squeak


Hola de nuevo :)

> >Totalmente de acuerdo en este punto. El namespace te da el
> > contexto en el que  se desenvuelve el nombre.
>
> A que contexto te referís?
> Los nombres no están en el espacio de los objetos, sino en
> el de su "definición", por lo que no sería correcto definir
> un espacio de nombres por contención.
>

Ok, me refer´ia al contexto en el que se desenvuelve la clase, el contexto
declarativo. EJ MyApp::State el State en el contexto de MyApp

Los contextos, como los conocemos, son contextos de
> ejecución, y definidos por un espacio de tiempo en
> donde interactúan objetos concretos.
>

Sisi,  yo dije "contexto" y vos entendiste "contexto" (somos objetos
diferentes entendemos de forma diferente los mensajes; mi "contexto"
pertenece a un contexto diferente al tuyo ;-))

Por otro lado, el nombre es solo eso, no cumple
> un rol en el sistema (de objetos) y como tal es un
> elemento pasivo (no puede desenvolverse en el
> sistema objeto, lo hace en el meta-sistema).
>

Agree

Ante mi POV, con la nominación alcanza, pues considero
> que su valor es tal para quien solo piensa en declarar un
> sistema (para quien busca trabajar con código/diseño
> y no con objetos).
>

este...no entiendo tu punto de vista... para trabajar con objetos tenes que
nombrarlos de alguna manera (no a los objetos, sino a sus clases), y en este
punto a mi particularmente me ayudan los namespace. Poner un prefijo a cada
nombre o hacer nombres de clases quilometricos no es algo que me guste y me
parezca "comodo"

Si trabajas declarativamente.
> Por ejemplo, en C++ y Java, dónde SOLO podes trabajar
> declarativamente -y es conveniente que solo trabajes así-
> es de mucho valor usar nombres compuestos.
> Trabajando con objetos no es tan determinante el usarlos.
>

Puede ser, pero a mi entender ayuda (al desarrollador no al sistema. Pero en
definitiva el que desarrolla es el desarrollador no? si me haces un sistema
que diseñe e implemnte sistemas, ahi si te voy a dar la razon que los
namespaces son totalmente inutiles, pero mientras el que tenga que
desarrollar el sistema tenga que ser yo, voy a quere namespaces (tal vez sea
un poco terco pero soy asi :-)) )

> y más si se quiere hacer un desarrollo distribuido (en más de
> >una persona :)).
>
> No opino igual :-)
> Siempre es conveniente promover la interacción entre las personas
> y es determinante en los costos de producción a mediano y largo plazo.
>
Las ventajas de usar Smalltalk incluyen el trabajar en equipos
> reducidos lo que hace mas fácil una dinámica orgánica en
> dónde las personas no divergen productivamente sino que trabajan
> en paralelo, sin implicar esto ultimo desperdicio de recursos por
> duplicaciones.
>

aja, pero tambien se pueden evitar duplicaciones utilizando namespaces :-)

> imaginate si se desarrollan X módulos de forma
> > independiente, que tienen nombres en común como State o Type
> > y que después se quieran unir.
>
> 1.- aprovecharía para sacar del equipo a quienes usen esos nombres...
>    sacarlos por un tiempo hasta que aprendan la lección y luego
>    seguramente se incorporarán dándole la importancia que tiene el
>    elegir nombres.
>

La importancia la tiene porque no tenes namesapaces. Es como tener un path
relativo o un path absoluto.

2.- si el daño "ya esta hecho", hay que poner (poca) energía para
>     repararlo. Y mucha mas energía para educar a quienes trabajaron
>    de esa forma.
>

De acuerdo con la filosofia, no se si se aplica aca. Tal vez este "mal
educado" ;-)

En otras palabras (y tratando de que lo de arriba no sea malentendido :)
> educar en la selección de nombres y en el valor que tiene la nominación
> de objetos (q sea consensuada) es costoso, pero importante
> en el caso de usar objetos.
> En los equipos dónde se trabaja declarativamente y/o no se puede
> dar el lujo de educar, se permite a los miembros del equipo
> trabajar aislados.
>

Ok, igualmente no es solo por el trabajo aislado o no (siempre es bueno
tener buena interaccion) . Pero supongamos que el dia de mañana tenes alguna
extension, o lo necesitas integrar en otro sistema, con namespaces te
ahorras coliciones y algunos dolores de cabeza (seguramente los menores y
mas simples, pero te los ahorras, entre pagar 0.1 y no pagar, prefiero no
pagar ;-))

>Obvio que se pueden modificar los nombres anteriores
> >anteponiendo el Namespace (NamespaceClase) pero es algo
> > que "molesta" al desarrollo y a mi entender perjudica la lectura
> > del código, en definitica, a mi entender no es práctico.
>
> Ahh! entonces no uses código.
> Construí un sistema.
>

Aja... y como hago eso?

>
> Me refería a que si se ve lindo, queda...
> hasta que alguien "pase y lo limpie" :-(
> (varias veces mucho tiempo mas tarde)
>

:-(

"linda" ? como el éxito es siempre subjetivo... :-)
> "escalable" ? solo hay que agregr objetos, si usaste objetos
> no habría razón por la que no pudiera escalar.
>

NO no no. No por el solo hecho de usar objetos las cosas escalan. Las cosas
escalan por una metodologia usada. Siempre se puede hacer moco en todo
paradigma y todo lenguaje.

Trabajando declarativamente, si hay problemas de escalabilidad,
> pero casi siempre por negación de sus costos (y no previsión de
> la energía que lleva cambiar un sistema, mas aún cuando uno
> no esta EN el sistema).
>

?

Espero no te desanime lo que dije...
>

para nada. Cuando tenga mas tiempo y realmente los necesite, los
implementare y listo. El poder "estar en el sistema" me deja moldearlo a mi
necesidad particular :-).

Cuando construimos un sistema con objetos,
> decimos: "este es mi sistema"
> el "mi" en "mi sistema" define una relación
> como la que está presente en :
>   Mi Dios, Mi Amor, etc...
> Dónde el objeto no es para nosotros, sino al revés.
>

No se que relacion tendras vos con "tus" sistemas, pero yo intento
construirlos para facilitarme el trabajo futuro, para que me resuelvan la
problematica actual, para que se adapte a mis necesidades y no al revez

>
> Cuantas colisiones tenes en lo que estás portando?
> Si podes, decinos de que porcentaje de nombres
> colisionados estamos hablando,como para darnos
> una idea de la gravedad del "problema" :-)
>

Jeje, para serte sincero, no es mucho, y se soluciona sin namespaces; pero
igualmente me interesaria la idea de tener namespaces.


hasta pronto,
>
> Ale.
>


--
Saludos Chiara

"Peace cannot be kept by force; it can only be achieved by understanding."
Albert Einstein

Hola Fernando,

>> Quizás después de +30años ya podríamos empezar a
>> pensar mas allá de los argumentos de los creadores :-)
>Probablemente si no se hiciera esto, muerto Kay quedaría
> muerto el Smalltalk (no habría evolución posible). En este
> punto sería interesante ver si hay alguna línea de evolución
> de Smalltalk en general, o de alguna implementación en
> particular (creo que la hay hasta donde pude ver, pero
> mi opinión es muy tangencial, tanto como tratamiento
> del Smalltalk).

Creo que desde la formulación del principio de homogeneidad,
  es (teóricamente) imposible la existencia de un avance real
  en términos de agregado/cambio de objetos. Pienso que
  con la formulación hecha en Smalltalk, y con su implementación,
  ya se ha logrado escapar a los limitantes dados por los
  lenguajes previos (el dibujo de globo es categórico y muy
  claro en al enunciación de esto que comento).

El planteo de que todos son objetos interactuando,
  genera una sensación de limite infinito que hace posible
  cualquier cosa imaginable (siempre y cuando sea imaginada).
Y sirve como formulación teórica...

En la práctica se encuentran las limitaciones, o mejor dicho,
  las consecuencias de aplicar esta formula.
Y están dadas por los "efectos secundarios" de la construcción
  de una solución imaginada.

Si hay puntos en dónde innovar, creo que son en el plano
  del reconocimineto de los limites de lo declarable;
  y allí es dónde se acaba la ayuda de lo ya impuesto/conocido.
En ese punto, en el abordaje de los efectos del trabajo
  orientado a objetos, es dónde no hay avance alguno; e incluso
  hay una negación constante de parte de quienes formularon
  Smalltalk en el 80.

En esa dirección, formulé la propuesta de Smalltalking;
  propuesta que he explicado y alentado a la creación de
  grupos de avance; pero sin éxito relevante en la concreción
  de resultados de valor.
Sin animo de derivar hacia temas ya tratados aquí y que han
  generado polémica en su momento, dejo la pelota picando...
  con la intensión de que la tome quien desee explorar un
  camino original.

>> Y la diversidad de características que pueden observarse
>> en el ambiente (el general o el propio/modificado) permite
>> satisfacernos sin tener que cambiar de ambiente (cosa que,
>> dado el estado actual, sería casi imposible, en mi opinión,
>> por no existir otro ambiente que se use comercialmente
>> de forma exitosa)
>Esto por lo menos habla de una elección meditada y no un
> simple "fundamentalismo fanatista smalltalkero", algo que
> suele producirse en ciertas comunidades más o menos
> separadas de la corriente principal.

Concuerdo que el fanatismo es algo que se da en ámbitos
  marginales (como Smalltalk); entablar diálogo
  con fanáticos aburre...
El no ser fanático, irrita a la mayoría de la gente (a quien
  no piensa igual, y a quien dice que piensa igual, pero no
  le da como para serlo y debe conformarse con ser
  una copia de cartón).

Un fanático es aquél que ve varias alternativas,
  elige una, la hace suya, y la defiende a muerte.
Yo no soy fanático, pues no veo alternativas.

>> En esos términos (de definición como lenguaje)
>> es donde perdemos el mayor valor de Smalltalk.
>> Perdemos la capacidad de que sea otra cosa.
>> Si algo (lo mas mínimo de esa definición) cambiara,
>> podríamos decir que tenemos algo que NO es
>> Smalltalk; obtenido por un cambio de Smalltalk.
>Esto me hace acordar a la discusión filosófica de si
> es posible definir a la"nada"...

Es posible definir algo que no es un objeto?
Si claro! se le pone un nombre y se lo reduce a un objeto.
Así de fácil.
Es de mucho valor el hacerlo, a la hora de enseñar.
Pero nunca debe olvidarse de enseñar dónde
  están los limites de esta simplificación que se ha hecho.
Con Smalltalk (y muchas otras cosas) ocurre que
  los limites no se exploran, se ocultan, se niegan...
Por justamente, no poderlos definir claramente.

A mi me hace recordar a que Object está planteado
  como subclase de nil...
Intentando dar fin a toda duda, sobre que todo es
  un objeto y negando la existencia de una "cosa"
  (un nominable que no es un objeto; ya hablamos
  varias veces de esto aquí).
Como una burla (creo yo) aparece una superclase
  que es formulada como ProtoObject (o similares);
  ocultando aún más el hecho de que hay
  cosas... que no son objetos (fijate que sigue
  teniendo el "Object"...en el nombre)

>Quiero decir, Smalltalk tendrá su definición (sino
> sería difícil su existencia, o peor no me imagino
> a A. Kay tratando de convencer a medio PARC
> de inventar algo que no tiene definición),

Creo que hubiera sido A. Goldberg y no Kay el
  que hubiera tenido que convencer... :-)
Kay definió una sintaxis.

> solo que no se ajusta a los parámetros usuales usados
>para definir un lenguaje (como querer explicar la
> tridimensionalidad de un cuerpo
>en un espacio de 2D - te perdés parte de la info
> por bajar una dimensión).

Si lo formulas como una alternativa, la perdes;
  si lo formulas como un complemento suma
  una dimensión (ortogonal).

El mayor desafío, a mi entender, es promover
  una extensión en un espacio ortogonal a los objetos;
  pues fuerza a que se aplique sobre las personas
  (y estas no desean mas de "lo que tienen",
  desean seguir replicando lo mismo; ser parte de
  un engranaje de una maquinaria de objetos que
  necesita mas objetos...).

>> Esta característica "orgánica" de Smalltalk produce efectos
>> maravillosos, confusos, ignorados y negativos según a
>> quién se le presenten...
>Sobre todo si a quien se le presentan no está "avisado"
> que esas cosas pueden aparecércele. Y lo que es peor,
> seguirá buscando cosas que jamás encontrará. Por eso
> más que una definición, sí es importante una "aclaración"
> para avisarle a los que nunca vivieron un Smalltalk, cuales
> son las cosas que podrían ocurrirle. Presumo que mucha
> gente pasa de largo por la puerta de Smalltalk, porque
> hay mucha otra que no tuvo la oportunidad de encontrarse
>con un cartel que le dijera "ojo, esto es diferente a lo que
> Ud cree común por "H", "B", "Z", etc".

Creo que no ocurre así.
En los cursos siempre se indica que Smalltalk es distinto
  (incluso lo hacen personas que no pueden explicar
  porque es distinto y/o que cuando intentan explicarlo,
  la gente no ve la diferencia...); en los foros también
  ocurre con frecuencia que se marcan diferencias (muchas
  veces de forma escueta, por... lo breve del medio, mmm)

Pienso que no alcanza con decirlo y en la mayoría
  de los casos ocurre que la gente no espera algo distinto,
  no esta educada para utilizar alternativas. Observo con
  frecuencia que se busca elegir una u otra opción,
  como si no fuera posible complementar.
Incluso es muy usado el argumento "paradigmático" en
  dónde se trata de plantear una ortogonalidad como
  si fuera excluyente (y no complementaria).

>> Lo complejo es complejo, no puede simplificarse;
>> si se simplifica, se reduce... se abstrae.
>> Lo que obtenes es una abstracción de lo complejo.
>> Esa abstracción no es lo complejo.
>> El valor de una abstracción está en que es un instrumento
>> que permite predicción (inventar el futuro...)
>> y aplicabilidad; pero para poder aplicarla
>> se requiere de algo que NO esta en la abstracción
>> y para peor de males, los efectos "secundarios"
>> de la aplicación son generalmente impredecibles y no
>> relacionados con la abstracción de origen.
>La simplificación de lo complejo solamente tiene
> sentido a nivel de la explicación del fenómeno,
> no del fenómeno en sí mismo.
>Explicar la dualidad de comportamiento de la
> luz (onda-partícula) puede simplificarse tanto
> como sea necesario como para exponerlo
> en los distintos niveles de la enseñanza, pero
> ello no hace (por más que uno se empecine)
> en simplificar el proceso físico.

Si, por esa razón, no debemos confundir a quien aprende,
pensando que el enunciado (valido para enseñar) tiene
  un éxito garantido al aplicarlo en la realidad. :-)
La extrapolación de los instrumentos "didácticos"
  ala realidad, es muchas veces invisible a
  quien "ya aprendió".
Y cuando sale de la escuela se encuentra
  con otras formas de pensar/actuar y que
  tiene que aprender, ahora solo, dónde
  están los bordes de lo que se le enseño.

El carácter marginal de Smalltalk permite estas
  expuesto a los bordes y esto no es soportado
  por la mayoría de quienes piensan que ya "terminaron
  de aprender" y de quienes se cansan de no tener
  "frutos" de su avance sobre esos bordes.

>Sí es de genios sintetizar en palabras
> simples conceptos complejos
> (si cualquiera pudiera entender
> la física, seríamos todos genios, jeje)

El propósito de simplificar, es evitar que otros
  estén expuestos a los bordes de los que hablaba.
Esta es una política cuya aplicación determina
  una de las razones por las que Smalltalk no
  podría ser popular.

>Así es el proceso de aprendizaje, de la física,
> de la vida o el mismísimo Smalltalk.

Si, estoy de acuerdo;
Aunque pienso que con Smalltalk se renueva
  la posibilidad de escapar a esa política en
  la Informática.
Escape imposible tanto para la física como
  para la enseñanza.

>Pero obviamente, y como parte de este
> proceso, es preciso ir escalando en la
> complejidad (o desandado el camino de las
> simplificaciones) para alcanzar el punto
> inicial (el de la complejidad
> del fenómeno en su real dimensión).

Pensas que se logra "entendiendo mas cosas" ?
Agregando libros a nuestra biblioteca?
Agregando objetos a un ambiente?

Opino que no es cuestión de contenidos.
La problemática de ambiente no se define
  por contención/adición.
Tampoco se puede plantear evolución
  de un ambiente; sino de sus "especies",
  que son una formalización dinámica,
  pero del espacio de las representaciones.
Permitime desconfiar del camino del
  entendimiento. :-)

>> mmm... buena pregunta...
>> como hacemos para que lo entienda?
>> Muchos creen que mentir es apropiado [*]
>> y que algún día alguien les dirá "la verdad"
>> (en otro curso?).
>Bueno, eso si pensas en mentir o, que simplificar
> es mentir. Nuevamente voy a lo mismo: no podés
> largarle todo de una, porque lo único que vas
> a conseguir es que tu interlocutor salga corriendo
> (o pensando que estás del tomate),

Ah! entonces queremos que sea bueno y rápido? :-)
Imposible.

> porque sin anestesia saliste hablando (ni siquiera
> explicando) un paradigma tan radicalmente
> diferente,

Complementario.

> que así no es difícil entender porque a muchos
> no les cae simpático el Smalltalk (si sería una
> buena táctica para mantenerlo dentro de una
>comunidad aislada que no quiere comunicarse
> - que es bastante impráctico)

No lo es.
El que sea una comunidad pequeña implica
  un estado de la mayoría.
La popularidad, no lo hace mas valioso;
  si esa popularidad implica que sea usado
  para lo mismo (escribir programas fuente
  o implementar diseños "bien pensados").

>>Me parece muy valioso de un ambiente el que puede
>>usarse para reforzar justamente esta sensibilidad.
>>Nos hace pensar siempre en hacer cosas sin dejar
>>de sentir al mismo tiempo si rompimos algo.
>>Y si ocurre ese "accidente", nos incita a arreglarlo
>>inmediatamente (a veces cerrando las ventanas cuanto
>>antes mejor :-P ) antes que dinamitar todo y volver al editor...
>>Hoy en día ni los médicos están educados en usar la
>>sensibilidad de la que hablo y que nos permite el uso
>>de Smalltalk.
>En realidad es una suerte que los médicos no tengan
> esa facilidad de decir "oops, me equivoque,
> reseteemos al paciente".

Quizás no has tenido aún una situación como para
  darte cuenta que ocurren cosas peores que esa.
Causadas principalmente, por expertos en tratar
  a todo como un objeto.
Te duele el ojo? tomá esto...
Te duele ahora la panza... tomá esto?
  y así hasta que ya nada duela.
Lo de la medicina, es un ejemplo, se aplica
  en todo la misma política, la misma "forma de saber"
  sin usar la percepción tratando solo de dirigir el futuro.
Si es posible inventarlo...
  y  veces patentarlo.

> Menuda suerte la nuestra en calidad de pacientes
> si los médicos aprendieranmedicina a base
> de ensayo-error...

No si lo hicieran antes entre ellos...

>>[*] pues de serlo, estoy completamente seguro que sería
>>una combinación "conveniente" de las demás.
>¿Acaso crees temes enunciar la Teoría del Campo Unificado?
>(si pudieras hacerlo, te harías más famoso que con el Smalltalk)

No me motiva crear otra teoría.
Creo que no se requiere encontrar otro objeto (teoría como
  queramos llamar a la formula).
El desafío, creo, está en promover a dejar de actuar igual. [*]

hasta pronto,
Ale.
[*] rechazar los xx segundos de fama que nos
  inventó Andy Walhol




----- Original Message -----
From: "Fernando José Velo Pérez" <fxveloperez@...>
To: <smalltalking@...>
Sent: Monday, July 10, 2006 10:11 PM
Subject: Re: [objetos] Smalltalk: segun la wikipedia


>> Aprovecho y aporto (destripen a gusto ;) aunque para mi el
>> pasado de Smalltalk es importante, por mas que no sea para
>> entender la intención de sus creadores - ya lo dijo AKay:

> Quizás después de +30años ya podríamos empezar a
> pensar mas allá de los argumentos de los creadores :-)

Probablemente si no se hiciera esto, muerto Kay quedaría muerto el Smalltalk
(no habría evolución posible). En este punto sería interesante ver si hay
alguna línea
de evolución de Smalltalk en general, o de alguna implementación en
particular
(creo que la hay hasta donde pude ver, pero mi opinión es muy tangencial,
tanto
como tratamiento del Smalltalk).

>> "Debería haberlo llamado POM (Programación Orientada a
>> Mensajes)" y creo que los que nos sentimos cómodos con
>> Smalltalk vemos esa diferencia... aquellos que no, siguen
>> centrándose en la estructura en vez de la interacción...

> El centrarse en los mensajes es igual de condicionante
> que centrarse en el objeto.
> Como posturas son validas las dos, y muy útiles,
> por cierto.
> En el caso de centrarnos en el objeto nos permite
> hacer analogías con lo corpuscular y encapsulado;
> da la seguridad característica de los sistemas cerrados.
> En el caso de centrarse en los mensajes, nos permite
> clasificar los elementos del lenguaje y ordenar "el diálogo"
> en protocolos, etc... permitiéndonos cerrar el sistema
> en la forma en que los objetos actúan.

> Creo que ambas formas de trabajo son aplicables y usadas
> en un ambiente como Smalltalk; pero no se si esto alcanza
> para atribuirle los méritos de hacernos sentir cómodos.
> Aunque seguramente el peso de una característica, u
> otra (y de otras que aquí no tratamos) sean de importancia
> para uno u otro; es decir, creo que la comodidad y
> conformidad con Smalltalk esta definida por los valores
> personales que pueden verse realizados al usar el ambiente.



> Y la diversidad de características que pueden observarse
> en el ambiente (el general o el propio/modificado) permite
> satisfacernos sin tener que cambiar de ambiente (cosa que,
> dado el estado actual, sería casi imposible, en mi opinión,
> por no existir otro ambiente que se use comercialmente
> de forma exitosa)

Esto por lo menos habla de una elección meditada y no un simple
"fundamentalismo fanatista smalltalkero", algo que suele producirse
en ciertas comunidades más o menos separadas de la corriente
principal.



>>  Una de las razones de porque Smalltalk es tan difícil de
>>  definir es que tradicionalmente se define un lenguaje en
>>  base a una sintaxis (BNF y cosas similares).  En dichas
>>  representaciones debe existir una completitud que abarque
>>  'todo' el lenguaje de forma no-ambigua.  El problema radica
>>  en lo siguiente:
>>
>>  Smalltalk es un ambiente de objetos donde todo objeto es
>>  instancia de alguna clase, pero no existe ninguna sintaxis
>>  para la definición de una clase!

> En esos términos (de definición como lenguaje)
> es donde perdemos el mayor valor de Smalltalk.
> Perdemos la capacidad de que sea otra cosa.
> Si algo (lo mas mínimo de esa definición) cambiara,
> podríamos decir que tenemos algo que NO es
> Smalltalk; obtenido por un cambio de Smalltalk.

Esto me hace acordar a la discusión filosófica de si es posible definir a
la"nada"...
Quiero decir, Smalltalk tendrá su definición (sino sería difícil su
existencia, o peor
no me imagino a A. Kay tratando de convencer a medio PARC de inventar algo
que no tiene definición), solo que no se ajusta a los parámetros usuales
usados
para definir un lenguaje (como querer explicar la tridimensionalidad de un
cuerpo
en un espacio de 2D - te perdés parte de la info por bajar una dimension).

> Justamente ahí es dónde se hace una ruptura
> entre Smalltalk y los lenguajes...
> ahí es dónde se ve la importancia de decir
> que NO es un lenguaje.
> En un Smalltalk, todo puede cambiar; pero cada Smalltalk
> es una instancia [*] (cada ambiente tiene un origen en esa
> matriz original Smalltalk/80) y como tal su máximo valor
> está en su IDENTIDAD.
> Como en un organismo, si en la edad avanzada,
> no encontramos células que estuvieran vivas en
> el nacimiento; igual decimos que se preservó la
> identidad! que es el mismo...

> Esta característica "orgánica" de Smalltalk produce efectos
> maravillosos, confusos, ignorados y negativos según a
> quién se le presenten...

Sobre todo si a quien se le presentan no está "avisado" que esas cosas
pueden aparecércele. Y lo que es peor, seguirá buscando cosas que jamás
encontrará. Por eso más que una definición, sí es importante una
"aclaración"
para avisarle a los que nunca vivieron un Smalltalk, cuales son las cosas
que
podrían ocurrirle. Presumo que mucha gente pasa de largo por la puerta de
Smalltalk, porque hay mucha otra que no tuvo la oportunidad de encontrarse
con un cartel que le dijera "ojo, esto es diferente a lo que Ud cree común
por
"H", "B", "Z", etc".


> > >>  En mi opinión, el resultado no es dependiente del
> > >>  autor.
> > >>  En otras palabras, conozco varios textos de autores,
> > >>  dignos de escribirse con mayúsculas, que han logrado
> > >>  producir textos de las mismas características (o solo
> > >>  un poco mejor) que el texto de wikipedia.
>>
>>  Nah... cualquier incompetente puede complejizar lo simple;
>>  pero hace falta un genio para simplificar lo complejo.

> Lo complejo es complejo, no puede simplificarse;
> si se simplifica, se reduce... se abstrae.
> Lo que obtenes es una abstracción de lo complejo.
> Esa abstracción no es lo complejo.
> El valor de una abstracción está en que es un instrumento
> que permite predicción (inventar el futuro...)
> y aplicabilidad; pero para poder aplicarla
> se requiere de algo que NO esta en la abstracción
> y para peor de males, los efectos "secundarios"
> de la aplicación son generalmente impredecibles y no
> relacionados con la abstracción de origen.

La simplificación de lo complejo solamente tiene sentido a nivel
de la explicación del fenómeno, no del fenómeno en sí mismo.

Explicar la dualidad de comportamiento de la luz (onda-partícula)
puede simplificarse tanto como sea necesario como para exponerlo
en los distintos niveles de la enseñanza, pero ello no hace (por más
que uno se empecine) en simplificar el proceso físico.

Sí es de genios sintetizar en palabras simples conceptos complejos
(si cualquiera pudiera entender la física, seríamos todos genios, jeje)

Así es el proceso de aprendizaje, de la física, de la vida o el mismísimo
Smalltalk. Pero obviamente, y como parte de este proceso, es preciso
ir escalando en la complejidad (o desandado el camino de las
simplificaciones) para alcanzar el punto inicial (el de la complejidad
del fenómeno en su real dimensión).


> > >>  El resultado final y los efectos que produce
> > >>  puede (y debe) evaluarse pero en base a lo que produce;
> > >>  no en base a las intensiones de los que han aportado.
>>  Las intenciones son evaluables... es básicamente lo que
>>  hace la diferencia entre accidente y sabotaje, negligencia
>>  o crimen, logro o suerte...  El ignorar las intenciones es
>>  convertir en irrelevante el bagaje cultural, social etc. de
>>  tu interlocutor lo que puede originar demasiados
>>  malentendidos...  Como explicarle a un beduino el oceano?
>>  A un bosquimano el concepto del dinero?  A un programador
>>  la idea de enviar mensajes en vez a invocar funciones?

> Es tan difícil como hacerle entender que
> un mensaje "le llega" a un objeto...
> cuando le dijiste que un objeto no
> es corpóreo y el espacio informático no es físico.

> Es tan difícil como hacer que entienda que
> la información no es un objeto...

> mmm... buena pregunta...
> como hacemos para que lo entienda?

> Muchos creen que mentir es apropiado [*]
> y que algún día alguien les dirá "la verdad"
> (en otro curso?).

Bueno, eso si pensas en mentir o, que simplificar es mentir.
Nuevamente voy a lo mismo: no podés largarle todo de una,
porque lo único que vas a conseguir es que tu interlocutor salga
corriendo (o pensando que estás del tomate), porque sin anestesia
saliste hablando (ni siquiera explicando) un paradigma tan radicalmente
diferente, que así no es difícil entender porque a muchos no les cae
simpático
el Smalltalk (si sería una buena táctica para mantenerlo dentro de una
comunidad aislada que no quiere comunicarse - que es bastante impráctico)



>> Concuerdo con que a la larga, es el resultado lo
>> importante, pero para eso están los historiadores... ;)

>Esto nos haría por siempre vírgenes (pues para ser
>historiadores deberíamos nacer de nuevo,
>tendríamos el mismo problema que los físicos...
>que deben ser matemáticos :-).
>Creo que podemos usar la percepción/sensibilidad,
>que no necesitamos recurrir a la historia (pues casi
>siempre la historia es "la de otros" y nunca podemos
>saber si la situación es la misma).
>Me parece muy valioso de un ambiente el que puede
>usarse para reforzar justamente esta sensibilidad.
>Nos hace pensar siempre en hacer cosas sin dejar
>de sentir al mismo tiempo si rompimos algo.
>Y si ocurre ese "accidente", nos incita a arreglarlo
>inmediatamente (a veces cerrando las ventanas cuanto
>antes mejor :-P ) antes que dinamitar todo y volver al editor...
>Hoy en día ni los médicos están educados en usar la
>sensibilidad de la que hablo y que nos permite el uso
>de Smalltalk.

En realidad es una suerte que los médicos no tengan esa facilidad
de decir "oops, me equivoque, reseteemos al paciente". Menuda
suerte la nuestra en calidad de pacientes si los médicos aprendieran
medicina a base de ensayo-error...


> > >> Se entiende lo que quiero decir. no?
> > >>  "Encender una luz, es proyectar una sombra"
>> Sombras?  Solo si hay obstáculos...

>Si vos sos, hay sombra.
>El actor es quien fuerza la sombra; en el punto de vista
>que justamente no está mirando.
>Es un ejemplo de emergente; causado por definir
>un punto de vista (una identidad).
>Podemos "no ver" la sombra, pero ya sentiremos su presencia :-)

Tambien la sombra resulta cambiante, según la incidencia de la luz y desde
el lugar donde estés parado.

>[corte unos párrafos]
>> Cerrando con lo que empece (AKay y POM vs. POO)... lo
>> importante es la interacción, no si el mensaje es texto,
>> html, ondas de sonido... todas enriquecen y nos permiten
>> interactuar, haciendo caso omiso de si todas las i's tienen
>> punto y las t's rayita... :)

>Sisisi! son todas "teorías" complementarias.
>Lo que creo amerita promover, no es el "descubrimiento"
>de una teoría mas; sino la consideración de algo
>que no sea una teoría [*].

>[*] pues de serlo, estoy completamente seguro que sería
>una combinación "conveniente" de las demás.

¿Acaso crees temes enunciar la Teoria del Campo Unificado?
(si pudieras hacerlo, te harías más famoso que con el Smalltalk)

Alejandro y Chiara,

El thread tiene cosas interesantes (a favor y en contra de
los NameSpaces)... pero debo decir que en lineas generales
me encuentro mas de acuerdo con Chiara... :)

Porque?  Porque los NameSpaces, mas alla de un monton de
pros&cons, me *simplifican* ciertas cosas... principalmente
el tener que pensar nombres (y todos sabemos que bautizar
objetos no es algo trivial - mas bien fundamental).

Otra ventaja es que me encapsula abstracciones.  Asi como
un objeto (por medio de la definicion en su clase) me
encapsula el nombre con que se bautizan sus colaboradores,
un NameSpace me brinda ese mismo nivel de encapsulamiento
pero a una escala mayor.  Y eso lo considero algo muy
positivo.  De no tener encapsulamiento en los objetos, como
me aseguro que la variable (ergo el nombre del colaborador)
no esta siendo usado por alguien mas?

Tambien tiene sus contras... principalmente que es algo mas
bien estatico (como dice Alejandro) y que plantea nuevas
complejidades (ej: importar, exportar, resolucion de
conflictos, etc) pero bueno me parece que los beneficios
son mayores que los costos.

Particularmente si uno intenta integrar frameworks o cargar
varias cosas con nombres no-optimos (y no me digan que no
existen!)  El mundo esta lleno de codigo que no es de lo
mejor, cuyos nombres son confusos y hasta errados.  Tomemos
cualquier Smalltalk y veremos que sus abstracciones son
erradas (o poco claras) para ciertos dominios.  Por
ejemplo, digamos que estoy haciendo un sistema de
asistencia escolar; #Class ya esta tomado por el ambiente,
con lo cual debo recurrir a 'inventar' un nuevo nombre (ej:
StudentClass) y que despues se nos propaga a los mensajes
(si le pido #class estoy nuevamente en conflicto con el
ambiente, ergo tengo que definir el mensaje #studentClass;
y todo mi sistema o modelo se ve 'contaminado' por el
simple hecho de que hubo alguien que 'me gano de mano' en
usar el nombre).

Esta 'contaminacion' de los mensajes es algo que opaca,
desluce o hace mas criptico el codigo, y que podria ser
resuelto con lo que creo haber entendido de lo que dijo
Alejandro... y que explico aca (tanto para discutir el tema
como para verificar que fue lo que Alejandro quizo decir -
corregime si no lo es! :)

--------- code [1] begin ---------
Smalltalk.Core.Object>>class
	 "Answer the object which is the receiver's class."

	 <primitive: 111>
	 self primitiveFailed

Smalltalk.School.Enrolment>>class
	 "Answer the School.Class for the enrolled student."

	 ^class
--------- code [1] end ---------

Hasta aqui tendriamos la situacion donde un NameSpace
decide hacer un override del mensaje #class para acomodarlo
a *su* dominio...

Ahora el tema seria como deberia reaccionar el ambiente
ante un dado mensaje #class:

--------- code [2] begin ---------
Smalltalk.Core.SomeObject>>foo
	 "Example extra-namespace method..."
	 "The result would be an instance of Core.Behavior"

	 ^anObject class

Smalltalk.School.SomeObject>>foo
	 "Example intra-namespace method..."
	 "The result would be an instance of School.Class"

	 ^anObject class
--------- code [2] end ---------

En el primer metodo, el mensaje #class esta dentro del
Smalltalk.Core NameSpace y por lo tanto deberia mapearse
con el comportamiento definido en ese NameSpace -
especificamente Smalltalk.Core.Object>>#class

En el segundo caso, dado que el sender esta definido en el
NameSpace de Smalltalk.School, este envio deberia de
mapearse al Smalltalk.School.Enrolment>>#class

La idea me parece muuuy interesante... pero muuuuuuuuy
inmanejable (o peligrosa).  Este ejemplo es trivial (es un
getter al fin y al cabo) y si bien puede resultar en cosas
muy inesperadas, no cambia el estado de ningun objeto.

En cuanto empiece a modificar el estado y/o relaciones
entre objetos de esta manera puede tornarse extremadamente
dificil de saber que va a pasar cuando envio un mensaje.
Por ejemplo, supongamos (nuevamente) un Stream que en un
NameSpace le redefino el #next para que haga un #skip antes
de hacer el #next (no se, solo me interesa la mitad del
stream ;) pero me olvido de modificar el #skip:, #position
etc... el Stream puede quedar en estados incoherentes e
invalidos, en donde sus invariantes ya no lo son... y solo
porque 'extendi' el #next...

Alejandro, era esto (o similar) a lo que te referias??
Si es asi, mi comentario es que esta muy copado, pero poco
aplicable (o mejor dicho, una capacidad muy poderosa, ergo
peligrosa... hay que tener mucho criterio para su
utilizacion provechosa).

Si no era esto... podes explicar a que te referias?
Y obvio, ignoren todo lo anterior... :P

En fin, volviendo a los NameSpaces... no se, por un lado me
gustan y por otro lado me agregan una carga previamente
inexistente.  Particularmente si yo soy el autor de todo
(ya que yo bautice a todos mis objetos es dificil tener
demasiados conflictos inesperados).  Pero si estoy tratando
de reusar frameworks de otros, no tengo control sobre sus
abstracciones y sus nombres, con lo cual no quiero que me
afecten y los NameSpaces me proveen ese encapsulamiento...
y como vago que soy (soy un buen objeto - a veces) prefiero
integrar a desarrollar (je... delegacion maxima ;)

Sigo intercalando algunos comentarios... mas como notas al
margen que como temas... :)


  --- "Alejandro F. Reimondo" <aleReimondo@...>
escribió:

> Hola Chiara,
>
> >Hola Alejandro, gracias por la respuesta y por la
> tentativa de solución.
> >Asimismo no comparto tu punto de vista con respecto a
> los Namespaces.
>
> Reconozco que mi punto de vista es bastante particular
>  y poco frecuente en este tema. :-)

Cierto... eso no quiere decir nada per se... el tema es
lograr transmitirlo completamente :)

> > Los namespaces son valiosos para quienes entienden que
> > es deseable aumentar la capacidad declarativa de la
> > sintaxis de Smalltalk, para permitir declarar(de forma
> > previa) una nominación mas específica que la dada por
un
> > solo nombre.
> > Totalmente de acuerdo en este punto. El namespace te da
> > el contexto en el que  se desenvuelve el nombre.
>
> A que contexto te referís?
> Los nombres no están en el espacio de los objetos, sino
>  en el de su "definición", por lo que no sería correcto
>  definir un espacio de nombres por contención.
>
> Los contextos, como los conocemos, son contextos de
>  ejecución, y definidos por un espacio de tiempo en
>  donde interactúan objetos concretos.
>
> El concepto de espacio de nombres es al menos
>  "objetable". ;-)

Bueno... tecnicamente es cierto, el nombre es simplemente
una 'abreviatura/apodo' al objeto, pero usualmente ese
nombre entra en juego como nombre de mensajes... pero aun
asi, internamente, los objetos funcionan como unidad de
contencion para sus nombres de variables de instancia...

>
> Por otro lado, el nombre es solo eso, no cumple
>  un rol en el sistema (de objetos) y como tal es un
>  elemento pasivo (no puede desenvolverse en el
>  sistema objeto, lo hace en el meta-sistema).
>
> Ante mi POV, con la nominación alcanza, pues considero
>  que su valor es tal para quien solo piensa en declarar
>  un sistema (para quien busca trabajar con código/diseño
>  y no con objetos).

Esteee... el codigo y disenho son parte de los objetos.
Supongo que te estas refiriendo a un (avanzado) estado de
un eco-sistema de objetos donde no existen nuevas
abstracciones (solo re-combinaciones de las existentes) con
lo cual no hay que especificar las bases.
Desafortunadamente, cada vez que entramos en un nuevo
dominio (o lo revisitamos con nuestro actual estado mental)
las abstracciones presentes no alcanzan y nos vemos
'forzados' a especificar nuevas...

>
> >>Es un hecho reciente en Smalltalk,
> >> y en realidad (en la práctica es)  innecesario;
> >A mi entender no es del todo así. Teóricamente si puede
> > se innecesario ya que la posibilidad de nombres para
> > las clases es potencialmente infinita :-).
>
> No, no lo decía por eso...
> Lo decía en la practica, la Teoría...
>  ...me aburrió hace tiempo.
>
> >Pero a la hora de llevarlo a la práctica poder definir
> >tu namespace es algo que ayuda
>
> Si trabajas declarativamente.
> Por ejemplo, en C++ y Java, dónde SOLO podes trabajar
>  declarativamente -y es conveniente que solo trabajes
>  así- es de mucho valor usar nombres compuestos.
> Trabajando con objetos no es tan determinante el usarlos.

En ambos casos estas navegando una estructura de
referencias (violando la Ley de Demetrio)... solo que
cuando lo haces declarativamente dejas explicito el camino
que tomaste, mientras que si 'trabajas con objetos' el como
lo obtuviste es impenetrable ya que fue 'puesto' ahi por el
que manipulo los objetos... de donde lo saco??

(Obvio, si es que entiendo correctamente a que te referis
con 'trabajando con objetos'... ;))

>
> > y más si se quiere hacer un desarrollo distribuido (en
> > más de una persona :)).
>
> No opino igual :-)
> Siempre es conveniente promover la interacción entre las
>  personas y es determinante en los costos de producción a
>  mediano y largo plazo.
> Las ventajas de usar Smalltalk incluyen el trabajar en
>  equipos reducidos lo que hace mas fácil una dinámica
>  orgánica en dónde las personas no divergen
>  productivamente sino que trabajan en paralelo, sin
>  implicar esto ultimo desperdicio de recursos por
>  duplicaciones.

Eso es suponiendo un escenario totalmente bajo tu control.
A veces eso no es posible, eficiente o deseable.  Y no
siempre esta relacionado con el 'tamanho' del sistema.  A
veces es un tema de competencias, divide-y-conquistaras,
reuso, etc.  Y los NameSpaces (como dije) sirven para
encapsular esos 'espacios de abstracciones' que cada unidad
de desarrollo necesita.

>
> > imaginate si se desarrollan X módulos de forma
> > independiente, que tienen nombres en común como State o
> > Type y que después se quieran unir.
>
> 1.- aprovecharía para sacar del equipo a quienes usen
>     esos nombres... sacarlos por un tiempo hasta que
>     aprendan la lección y luego seguramente se
>     incorporarán dándole la importancia que tiene el
>     elegir nombres.
> 2.- si el daño "ya esta hecho", hay que poner (poca)
>     energía para repararlo. Y mucha mas energía para
>     educar a quienes trabajaron de esa forma.
>
> En otras palabras (y tratando de que lo de arriba no sea
>  malentendido :) educar en la selección de nombres y en
el
>  valor que tiene la nominación de objetos (q sea
>  consensuada) es costoso, pero importante en el caso de
>  usar objetos.

Mmm... casi Pavloviano lo tuyo... :P  Pero mas alla de los
aspectos pedagogicos, seguis partiendo del supuesto que vos
controlas absolutamente todo el desarrollo (al menos dentro
de la imagen) ergo inventaste (o re-invetastes) todas las
ruedas habidas y por haber...
En cuanto a que es 'poca' la energia, no estoy tan de
acuerdo, ya que para garantizar que todo lo que cambiaste
no tiene efectos colaterales es muy dificil... Por ejemplo,
cuantas veces hemos usado el simbolo/string del nombre de
una clase para operar sobre el?  El caso mas trivial seria
sacar los prefijos que la falta de NameSpaces nos forzo en
el nombre, otros seria obtener la subclase apropiada con la
cual hay que engancharse... cierto, todas esas referencias
podrian haber sido hechas por medio de mensajes (y metodos)
especificos, pero bueno, la gracia de tener un meta-sistema
es poder usarlo...


> En los equipos dónde se trabaja declarativamente y/o no
>  se puede dar el lujo de educar, se permite a los
miembros
>  del equipo trabajar aislados.
> (una analogía, algo extrema... pero creo que vale)
> Para reducir el delito, algunos piensan que hay que
>  usar vidrios polarizados.
> Otros piensan que es muy costoso.
>
> Con los nombres (de objetos y de mensajes) pasa algo
> similar.
>
> >Obvio que se pueden modificar los nombres anteriores
> >anteponiendo el Namespace (NamespaceClase) pero es algo
> >que "molesta" al desarrollo y a mi entender perjudica
> >la lectura del código, en definitica, a mi entender no
es
> >práctico.
>
> Ahh! entonces no uses código.
> Construí un sistema.

Aca me perdi... para construir algo necesito los planos.
Pueden ser mas o menos formales (ej: plano de arquitecto
aprobado por la municipalidad, un bosquejo en una
servilleta, o una idea mental algo borrosa).
Desafortunadamente las computadoras son muy burocraticas...
y quieren codigo!
Y por mas avanzado que tengas tu ambiente, siempre
necesitas el glue-code...

>
> >>En comunidades mas libres, comola de Squeak, esta
> >>presión no existe; y esa es una de las razones (creo)
> >>por la que una utilidad que no sea necesaria en la
> >>práctica no está presente.
> >Me parece perfecto. Pero me gustaría que alguien hubiera
> > solucionado este "problema" :(.
>
> Ante mi POV, te comentaba que,
>  no es un problema (luego no debería haber una solución).

Bueno, hay gente que destapa las botellas con casi
cualquier cosa (cuchillos, tenedores, mesas, dientes, etc.)
pero existe el objeto Destapador... La gente que solo sabe
abrir las botellas con el, tiene un problema cuando no lo
tiene y se queda con sed.  Por el otro lado, el que 'no
tiene problema' en abrirlas con cualquier cosa, de vez en
cuando rompe el cuello de la botella... y tambien se queda
con sed, o come vidrio... ;)

(Nota: 'Destapador' no esta calificado pero el contexto
habla de botellas y no de inodoros... el contexto es el
NameSpace).

>
> >>En todo Squeak se observa lo contrario a presiones
> >> respecto del "estilo" y se valora mucho más la
> >> estética del resultado que la forma en que está
> >> logrado, su estabilidad e incluso su calidad.
> >mmmm no se a que te referís acá. calidad en base a que
> criterio?
>
> Me refería a que si se ve lindo, queda...
>  hasta que alguien "pase y lo limpie" :-(
>  (varias veces mucho tiempo mas tarde)
>
> > mi criterio es el de programación "linda" y escalable,
> > por eso me gusta el diseño en objetos (aunque debo
> > confesar que usaba Java :s) y en particular Smalltalk.ç
>
> "linda" ? como el éxito es siempre subjetivo... :-)
> "escalable" ? solo hay que agregr objetos, si usaste
>  objetos no habría razón por la que no pudiera escalar.

Cierto, el exito es subjetivo.  La escabilidad tambien.  Y
los objetos no hacen algo escalable por esencia.  La
escalabilidad se encuentra -principalmente- en el disenho,
u en menor (pero crucial - el diablo esta en los detalles)
en su implmentacion.

>
> Trabajando declarativamente, si hay problemas de
>  escalabilidad, pero casi siempre por negación de sus
>  costos (y no previsión de la energía que lleva cambiar
>  un sistema, mas aún cuando uno no esta EN el sistema).
>
> >>Por esta razón, creo que si encontrás en Squeak algo
> >> "parecido" a NameSpaces, serán restos de algo que ha
> >> desaparecido (luego de algunos ensayos para demostrar
> >> su inutilidad práctica real).
> >:-(
>
> Espero no te desanime lo que dije...
>
> >>De vez en cuando en la lista de Squeak se gravita sobre
> >> este punto (en realidad sobre la problemática de la
> >> nominación dinámica; que es un tema más amplio y
> >> ambicioso).
> >> Cuando esto ocurre aparecen al menos dos reflexiones
> >> de forma recurrente:
> >> 1.- tener NameSpaces solo para nombres de objetos
> >> es una solución de corto plazo; pues en realidad lo
> >> útil sería poder extender el concepto a los mensajes
> >> (con lo que se complica mucho mas el tema).
> >este....

Mi 'modelo' de sobre-escritura al inicio del mail, era
esto??

> >>2.- que el naming sea estático (resuelto en durante la
> >> compilación) es algo inútil y solo resuelve las
> >> colisiones; es decir, no da servicio al sistema mismo,
> >> sino solo a las personas que lo escriben (declaran);
> >> por lo que no es un tema del sistema en si, sino de la
> >> sintaxis en que se expresa en texto... (si el sistema
> >> se construye con objetos, el problema desaparece, y se
> >> transforma en un tema del pasado)
> >No estoy de acuerdo.

Para mi no es inutil.  Tiene su utilidad.  Limitada.  Pero
no por ello deja de ser util, por mas que no sea un intento
en reducir la complejidad y minimizar conflictos entre
cosas que vos solo queres usar...

>
> En que parte(s)?
> (yo tampoco estoy deacuerdo en algunas de estas, es
>  lo que recuerdo de lo que se habló en la lista de
> Squeak)
>
> >Muchos usan un argumento parecido (no es problema del
> >"sistema") para justificar la falta de bloques en Java.
>
> :-) bastante inocente.
> No puedo responder por quien diría algo así.
> Q que se inscriba y lo ponga en esta lista,
>  así conversamos sobre lo que piensa de los bloques.
>
> > ERROR! el "sistema" tendría que facilitar la
> > programación y lograr que el programador se centre en
> > el qué y no en el cómo.
>
> El sistema?
> No tiene noción ni se entera de que hay alguien
> (generalmente un humano?) a quien debe servir...
> Un sistema de objetos abierto, como es un ambiente,
>  no tiene compromiso con su creador; no es para con él;
>  sino al revés.
> Vos sos para el sistema.

"Resistance is futile &#8212; you will be assimilated."??

Si bien estoy de acuerdo con que existen sistemas
(submundos) que 'cobran vida' mas alla de las intenciones
originales (ej: la web) yo diria que la gran mayoria de
sistemas dejarian de funcionar de no haber personas a su
alrededor.  Con lo cual estaria de acuerdo...

Pero, el compromiso del sistema para con su creador, si
bien no es explicito, es implicito: en cuanto su cohorte de
humanos que le dan soporte deciden que ya no es util,
muere.  Por lo tanto, el compromiso existe... de mantenerse
util.  Es incapaz de hacerlo solo, pero eso solo lo deja
indefenso... no necesariamente amo y senhor... es un rey,
pero que esta desnudo.

>
> Cuando construimos un sistema con objetos,
>  decimos: "este es mi sistema"
>  el "mi" en "mi sistema" define una relación
>  como la que está presente en :
>   Mi Dios, Mi Amor, etc...
> Dónde el objeto no es para nosotros, sino al revés.
>
> El sistema no facilita(ni perjudica) su creación,
>  si esta construido con objetos.

Poco importa con que esta construido...

>
> Si el sistema del que hablamos es un sistema cerrado,
>  el cual es posible (y a veces recomendable) definirlo
>  declarativamente; entonces si se aplica lo que vos
>  decías (dónde el sistema es el sistema usado para
>  conceptualizarlo/modelarlo); pero en ese caso
>  estaríamos hablando de trabajar solo Orientado a
>  objetos y no con objetos.
>
> >Namespaces ayuda un poquito, mínimamente, pero
> >ayuda.
>
> >>Ultima recomendación:
> >> Te decía que los NameSpaces no son peligrosos...
> >> Verificá bien como funciona lo que estás migrando,
> >>  pues los mas difícil de migrar de un Smalltalk a
> >>  otro es que hay diferencias que son sutiles y afectan
> >>  tanto perfomance como a veces son causales de fallas
> >>  imprevistas.
> >Ok, lo tendré en cuenta.
>
> No se si desestimaste la opción de definir el NameSpace
>  con el comportamiento de acceso...
> Creo que es una solución "elegante" (de las lindas :)
>  y que no te haría perder mucho tiempo.
>
> Cuantas colisiones tenes en lo que estás portando?
> Si podes, decinos de que porcentaje de nombres
>  colisionados estamos hablando,como para darnos
>  una idea de la gravedad del "problema" :-)
> Si el porcentaje es alto me sorprendería, pero
>  indica que está afectando de forma concreta el
>  producto y en este aspecto me gustaría hacer un
>  estudio de los NameSpaces.

La cantidad de colisiones no es importante.  Bueno si, pero
lo mas importante es el poder aislarlo.  El 'renombrar'
manualmente esos conflictos es una solucion temporal,
ineficiente y poco mantenible.  Por un lado, para
asegurarnos de haber redirigido correctamente todas las
referencias el trabajo es muy desgastante (principalmente
porque uno debe poder entender como funciona para saber que
cambiaste todas las referencias, aun las dinamicas y sus
implicancias).  Finalmente, despues de haber hecho todo ese
trabajo, lo hiciste todo dentro de una imagen y con un
'paquete' de objetos fuente.

El dia de maniana, cuando tengas que armar una nueva
imagen, o salga una nueva version vas a tener que rehacer
todo...


>
> gracias a vos!
>
> hasta pronto,
> Ale.
>
>
> ----- Original Message -----
> From: "Chiara" <muralito@...>

/Ether Plasm





__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

Hola,

>   Que necesidad te fuerza a implementar lo mismo en MT ?
>   La respuesta es, que quiero aprender sobre MT y 3D,
> no encuentro mejor manera que hacer este trabajo.

Ambos a la vez? mmmm :-)

Creo que quizás sería mas simple lograr en
Genesis3D+VisualSmalltalk lo que desees armar;
y luego, uan vez bien eentendido como manejarte
con Genesis3D, empezar a ver el tema de APIs
en MT...
Quizás es mejor que hagas el acceso vía API de algunas
librerías mas simples antes de Genesis3D; para evitar
que se te presenten problemas por ambos lados...

>   Me inscribi a foros de Games para ver que se
> puede hacer con los engine OO, ya que para su
> comunicacion con otros lenguajes implemtan un
> mecanismo de Scripting  que no se como
> funciona realmente.

En el ámbito de desarrollo de juegos lo "mas avanzado"
es scripting, es decir, incluir un interprete en el sistema
de juego y así permitir que un "usuario" modifique
escribiendo en lenguajes del tipo Basic, C o Java...
Esto es un gran avance con respecto a lo que había
antes; y muchos desarrolladores de juegos lo festejan
como si fuera lo máximo.
Incluso algunos engines tienen scripting OO!!!
con los que podes lograr tanto como lo que puede
lograrse con un PascalOO, "re"usando (en la forma
de entender el término como NO lo entendemos
aquí :) los componentes que exponen los diseñadores.

Toda analogía con el uso de un ambiente, termina
dónde uno empezaba a buscarla :-)

Hace varios meses (1 o 2 años creo) envié a esta
lista algunos links sobre el tema.

>   Vos me comentaste que lo ideal era hacer un API en C,
> estuve preguntando el los foros de C/C++ y nadie sabe
> como hacer esto.

Es lo que hacen los que trabajan con Cpuspus y desean
que sus componentes sean usados desde C, Pascal,
o Fortran...
En eso no hay ninguna particularidad relacionada con Smalltalk.
Como ejemplo... podes ver cualquier librería implementada
en C++ y que expone una API tradicional, como OpenCV,
o como la librería de partículas que uso junto con Genesis3D
  (que tenes en el image como ParticleProject)
  http://www.cs.unc.edu/~davemc/Particle
en dónde verás que pese a estar hecho en C++, se publica
una API tradicional y así puede usarse como si fuera C.
Fijate en la implementación de ParticleDLL y las subclases
de ParticleObject para ver como se usan en Smalltalk,
y en los fuentes de la librería para ver como se logra
el wrapper en C.

suerte,
Ale.


----- Original Message -----
From: "kikote gregoris" <kikogregoris@...>
To: <smalltalking@...>
Sent: Tuesday, July 18, 2006 10:18 AM
Subject: Re: [objetos] Help: Genesis3D


> Hola ALe
>
>   Todavía no consigo que funcione, pero no desespero.
>
>   Que necesidad te fuerza a implementar lo mismo en MT ?
>
>   La respuesta es, que quiero aprender sobre MT y 3D, no encuentro mejor
manera que hacer este trabajo.
>
>   En un futuro tenia pensado usar otro engine, como nebula 2 u otro.
>   El problema es que toda la nueva generacion de Engin3d esta desarrollada
en C++ y eso me complica la vida, mientras desarrollo este trabajo con
genesis3d estoy viendo de reojo otros alternativas mas modernas, pero como
te desia todos estan en C++ excepto el de Quake pero ademas de que la
licencia es astronomica (500000 $$) el motor es inentendible ya que hay una
licencia GNU y me descargue el codigo .
>
>   Tenes que ser un mago para entender como funciona la cosa y sin DOC
claro.
>   Me inscribi a foros de Games para ver que se puede hacer con los engine
OO, ya que para su comunicacion con otros lenguajes implemtan un mecanismo
de Scripting  que no se como funciona realmente.
>
>   Bueno cualquier cosa que puedas aportar te lo agradesco.
>
>   Vos me comentaste que lo ideal era hacer un API en C, estuve preguntando
el los foros de C/C++ y nadie sabe como hacer esto.
>   Buscando encontre como mapear una clase a una estructura y como hacer un
par de funciones en C para ejecutar los metodos de la clase, pero eso tiene
la desventaja que si la clase tiene miembros estaticos, el mapeo no funciona
por que estos miembros se guardan diferente en una clase.
>
>
>
>   saludos kiko
>
> "Alejandro F. Reimondo" <aleReimondo@...> escribió:
>   Hola kiko,
> Era a eso que me refería, pero veo que con cero esta bien...
> Fijate en el comment de GenesisEngine>>#render:with:time:
> pues allí dice algo que puede determinar la patología
> que estas sufriendo.
>
> Disculpame que pregunte... (no recuerdo si ya me lo dijiste)
> Que necesidad te fuerza a implementar lo mismo en MT ?
>
> hasta pronto,
> Ale.
>
>
>
> ----- Original Message -----
> From: "kikote gregoris" <kikogregoris@...>
> To: <smalltalking@...>
> Sent: Friday, July 14, 2006 11:36 AM
> Subject: Re: [objetos] Help: Genesis3D
>
>
> > Hola Ale
> >
> >   Esta es tu implementación del método que rendea todo.
> >   Si te referías al parámetro que le pasas a:
> >   # engine render: aWorld with: self camera time: 0"seconds".
> >   Como puedes ver es 0, si es que te referis a eso.
> >   Te aclaro que no se para que sirve este parámetro, ya que en la demo
que
> viene con genesis también le pasa 0
> >
> >
> >   render: aSpace in: aDevice for: aSpaceManager
> >               "Render the receiver's contents in aDevice."
> >
> >               | now elapsed aWorld engine seconds |
> >               rendering == true ifTrue: [ ^true ].
> >               aWorld := aSpace world.
> >               aWorld isNil ifTrue: [ ^true ].
> >               now := Time millisecondClockValue.
> >               elapsed := now - self lastRenderTime.
> >               elapsed < self minimumElapsedTime ifTrue: [ ^true ].
> >               self lastRenderTime: now.
> >               engine := aDevice engine.
> >               [ seconds := elapsed / 1000.0 ] on: ArithmeticError do: [
> ^true ].
> >               [          rendering := true.
> >                           [ aDevice renderStart
> >                             ifTrue: [
> >                                      self triggerEvent: #preRender:
with:
> seconds.
> >                                      (engine beginFrame: self camera)
> >                                      ifTrue: [
> >                                                  self triggerEvent:
> #startFrame: with: seconds.
> >                                                  self transform: aSpace
> at: seconds for: aSpaceManager.
> >                                                  self triggerEvent:
> #aboutToRender: with: seconds.
> >                                                  self
doNotDoTheFirstTime:
> [
> >                                                              engine
> render: aWorld with: self camera time: 0"seconds".
> >
> >                                                  ].
> >                                                  navigator notNil
ifTrue:
> [
> >                                                              navigator
> >
> overlay: aWorld seconds: seconds
> >
> for: aSpace in: engine
> >                                                  ].
> >                                                  self triggerEvent:
> #endFrame: with: seconds.
> >                                                  engine endFrame.
> >                                                  self triggerEvent:
> #postRender: with: seconds.
> >                                      ].
> >                                      aDevice renderStop.
> >                             ].
> >                           ] ensure: [ rendering := false ].
> >               ] value" evaluateWithoutInterrupts".
> >               ^trae.
> >
> >   Por ultimo, decir que estoy mas confundido que nunca, en la
> implementación que realice en VS pude crear GenesisFont y verlas, pero en
MT
> no pude, solo puedo ver el FrameRateCount y usar la función printf:at.
> >   No se, voy a seguir dandole manija a ver si sale algo mas.
> >
> >   Saludos kiko
> >
> >
> > "Alejandro F. Reimondo" <aleReimondo@...> escribió:  Si mal
> no recuerdo, al engine hay que pasarle (en cada render)
> > un indicador del tiempo de simulacion (es decir, cuanto hace que
> > no lo refrescas, en tics de simulación)...
> > Estas seguro de estar incrementando ese valor?
> > Quizas eso es lo que pasa, el engine peinsa que no paso
> > ningun tiempo desde que lo arrancaste y no hace una
> > actualización del buffer de rendering interno...
> > suerte,
> > Ale.
> >
> > ----- Original Message -----
> > From: "kikote gregoris" <kikogregoris@...>
> > To: <smalltalking@...>
> > Sent: Friday, July 07, 2006 11:13 AM
> > Subject: Re: [objetos] Help: Genesis3D
> >
> >
> > > Hola Ale
> > >
> > >
> > >   Cargue un actor y uso el mensaje #isActor:potentiallyVisibleWith:,
el
> > cual me retorna verdadero, pero no veo al actor.
> > >   Creía que podía ser un problema que tenga que ver con el tamaño del
> > actor, con lo cual me puse a escalarlo para ver que pasaba,pero nada.
> > >
> > >   Luego cargo un bitmap y uso el mensaje #isBitmapVisible, el cual me
> > retorna falso,
> > >    pero ya lo agregue y lo mostré con #displayBitmap:at:.
> > >
> > >   Alguna idea de lo que me pueda estar pasando????????
> > >
> > >   Saludos kiko
> > >
> > >
> > >  __________________________________________________
> > > Correo Yahoo!
> > > Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
> > > ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar
> >
> >
> >
> >
> > ---------------------------------
> >  Horóscopos, Salud y belleza, Chistes, Consejos de amor.
> >  El contenido más divertido para tu celular está en
> > Yahoo! Móvil
>
>
>
>
> ---------------------------------
>  Preguntá. Respondé. Descubrí.
>  Todo lo que querías saber, y lo que ni imaginabas,
>  está en Yahoo! Respuestas (Beta).
>  Probalo ya!

Hola gente!

 

Si es por buscar 3d game engines que no esten en C++, podrias ver

 

http://www.exocortex.org/3dengine/

http://www.taoframework.com/Home

 

desarrollados en .NET, aunque no se hasta que punto llegaron en el desarrollo.

 

Nos leemos!

 

Angel "Java" Lopez

http://www.ajlopez.com/

 

----- Original Message -----

From: kikote gregoris

To: smalltalking@...

Sent: Tuesday, July 18, 2006 10:18 AM

Subject: Re: [objetos] Help: Genesis3D

Hola ALe

 

Todavía no consigo que funcione, pero no desespero.

 

Que necesidad te fuerza a implementar lo mismo en MT ?

La respuesta es, que quiero aprender sobre MT y 3D, no encuentro mejor manera que hacer este trabajo.

 

En un futuro tenia pensado usar otro engine, como nebula 2 u otro.

El problema es que toda la nueva generacion de Engin3d esta desarrollada en C++ y eso me complica la vida, mientras desarrollo este trabajo con genesis3d estoy viendo de reojo otros alternativas mas modernas, pero como te desia todos estan en C++ excepto el de Quake pero ademas de que la licencia es astronomica (500000 $$) el motor es inentendible ya que hay una licencia GNU y me descargue el codigo .....

 

Hola Chiara,

>Hola Alejandro, gracias por la respuesta y por la tentativa de solución.
>Asimismo no comparto tu punto de vista con respecto a los Namespaces.

Reconozco que mi punto de vista es bastante particular
  y poco frecuente en este tema. :-)

>Los namespaces son valiosos para quienes entienden que
> es deseable aumentar la capacidad declarativa de la sintaxis
> de Smalltalk, para permitir declarar(de forma previa)
> una nominación mas específica que la dada por un
> solo nombre.
>Totalmente de acuerdo en este punto. El namespace te da el
> contexto en el que  se desenvuelve el nombre.

A que contexto te referís?
Los nombres no están en el espacio de los objetos, sino en
  el de su "definición", por lo que no sería correcto definir
  un espacio de nombres por contención.

Los contextos, como los conocemos, son contextos de
  ejecución, y definidos por un espacio de tiempo en
  donde interactúan objetos concretos.

El concepto de espacio de nombres es al menos "objetable". ;-)

Por otro lado, el nombre es solo eso, no cumple
  un rol en el sistema (de objetos) y como tal es un
  elemento pasivo (no puede desenvolverse en el
  sistema objeto, lo hace en el meta-sistema).

Ante mi POV, con la nominación alcanza, pues considero
  que su valor es tal para quien solo piensa en declarar un
  sistema (para quien busca trabajar con código/diseño
  y no con objetos).


>>Es un hecho reciente en Smalltalk,
>> y en realidad (en la práctica es)  innecesario;
>A mi entender no es del todo así. Teóricamente si puede
> se innecesario ya que la posibilidad de nombres para las
> clases es potencialmente infinita :-).

No, no lo decía por eso...
Lo decía en la practica, la Teoría...
  ...me aburrió hace tiempo.

>Pero a la hora de llevarlo a la práctica poder definir tu
> namespace es algo que ayuda

Si trabajas declarativamente.
Por ejemplo, en C++ y Java, dónde SOLO podes trabajar
  declarativamente -y es conveniente que solo trabajes así-
  es de mucho valor usar nombres compuestos.
Trabajando con objetos no es tan determinante el usarlos.

> y más si se quiere hacer un desarrollo distribuido (en más de
>una persona :)).

No opino igual :-)
Siempre es conveniente promover la interacción entre las personas
  y es determinante en los costos de producción a mediano y largo plazo.
Las ventajas de usar Smalltalk incluyen el trabajar en equipos
  reducidos lo que hace mas fácil una dinámica orgánica en
  dónde las personas no divergen productivamente sino que trabajan
  en paralelo, sin implicar esto ultimo desperdicio de recursos por
  duplicaciones.

> imaginate si se desarrollan X módulos de forma
> independiente, que tienen nombres en común como State o Type
> y que después se quieran unir.

1.- aprovecharía para sacar del equipo a quienes usen esos nombres...
    sacarlos por un tiempo hasta que aprendan la lección y luego
    seguramente se incorporarán dándole la importancia que tiene el
    elegir nombres.
2.- si el daño "ya esta hecho", hay que poner (poca) energía para
     repararlo. Y mucha mas energía para educar a quienes trabajaron
    de esa forma.

En otras palabras (y tratando de que lo de arriba no sea malentendido :)
  educar en la selección de nombres y en el valor que tiene la nominación
  de objetos (q sea consensuada) es costoso, pero importante
  en el caso de usar objetos.
En los equipos dónde se trabaja declarativamente y/o no se puede
  dar el lujo de educar, se permite a los miembros del equipo
  trabajar aislados.
(una analogía, algo extrema... pero creo que vale)
Para reducir el delito, algunos piensan que hay que
  usar vidrios polarizados.
Otros piensan que es muy costoso.

Con los nombres (de objetos y de mensajes) pasa algo similar.

>Obvio que se pueden modificar los nombres anteriores
>anteponiendo el Namespace (NamespaceClase) pero es algo
> que "molesta" al desarrollo y a mi entender perjudica la lectura
> del código, en definitica, a mi entender no es práctico.

Ahh! entonces no uses código.
Construí un sistema.

>>En comunidades mas libres, comola de Squeak, esta presión
>> no existe; y esa es una de las razones (creo) por la que una utilidad
>> que no sea necesaria en la práctica no está presente.
>Me parece perfecto. Pero me gustaría que alguien hubiera
> solucionado este "problema" :(.

Ante mi POV, te comentaba que,
  no es un problema (luego no debería haber una solución).

>>En todo Squeak se observa lo contrario a presiones
>> respecto del "estilo" y se valora mucho más la estética del
>> resultado que la forma en que está logrado, su estabilidad
>> e incluso su calidad.
>mmmm no se a que te referís acá. calidad en base a que criterio?

Me refería a que si se ve lindo, queda...
  hasta que alguien "pase y lo limpie" :-(
  (varias veces mucho tiempo mas tarde)

> mi criterio es el de programación "linda" y escalable,
> por eso me gusta el diseño en objetos (aunque debo
> confesar que usaba Java :s) y en particular Smalltalk.ç

"linda" ? como el éxito es siempre subjetivo... :-)
"escalable" ? solo hay que agregr objetos, si usaste objetos
  no habría razón por la que no pudiera escalar.

Trabajando declarativamente, si hay problemas de escalabilidad,
  pero casi siempre por negación de sus costos (y no previsión de
  la energía que lleva cambiar un sistema, mas aún cuando uno
  no esta EN el sistema).

>>Por esta razón, creo que si encontrás en Squeak algo
>> "parecido" a NameSpaces, serán restos de algo que ha
>> desaparecido (luego de algunos ensayos para demostrar
>> su inutilidad práctica real).
>:-(

Espero no te desanime lo que dije...

>>De vez en cuando en la lista de Squeak se gravita sobre
>> este punto (en realidad sobre la problemática de la
>> nominación dinámica; que es un tema más amplio y ambicioso).
>> Cuando esto ocurre aparecen al menos dos reflexiones
>> de forma recurrente:
>> 1.- tener NameSpaces solo para nombres de objetos
>> es una solución de corto plazo; pues en realidad lo útil
>> sería poder extender el concepto a los mensajes (con lo
>> que se complica mucho mas el tema).
>este....
>>2.- que el naming sea estático (resuelto en durante la
>> compilación) es algo inútil y solo resuelve las colisiones;
>> es decir, no da servicio al sistema mismo, sino solo a las
>> personas que lo escriben (declaran); por lo que no es un
>> tema del sistema en si, sino de la sintaxis en que se expresa
>> en texto... (si el sistema se construye con objetos, el
>> problema desaparece, y se transforma en un tema del
>> pasado)
>No estoy de acuerdo.

En que parte(s)?
(yo tampoco estoy deacuerdo en algunas de estas, es
  lo que recuerdo de lo que se habló en la lista de Squeak)

>Muchos usan un argumento parecido (no es problema del
>"sistema") para justificar la falta de bloques en Java.

:-) bastante inocente.
No puedo responder por quien diría algo así.
Q que se inscriba y lo ponga en esta lista,
  así conversamos sobre lo que piensa de los bloques.

> ERROR! el "sistema" tendría que facilitar la programación
> y lograr que el programador se centre en el qué
> y no en el cómo.

El sistema?
No tiene noción ni se entera de que hay alguien (generalmente
  un humano?) a quien debe servir...
Un sistema de objetos abierto, como es un ambiente,
  no tiene compromiso con su creador; no es para con él;
  sino al revés.
Vos sos para el sistema.

Cuando construimos un sistema con objetos,
  decimos: "este es mi sistema"
  el "mi" en "mi sistema" define una relación
  como la que está presente en :
   Mi Dios, Mi Amor, etc...
Dónde el objeto no es para nosotros, sino al revés.

El sistema no facilita(ni perjudica) su creación,
  si esta construido con objetos.

Si el sistema del que hablamos es un sistema cerrado,
  el cual es posible (y a veces recomendable) definirlo
  declarativamente; entonces si se aplica lo que vos
  decías (dónde el sistema es el sistema usado para
  conceptualizarlo/modelarlo); pero en ese caso
  estaríamos hablando de trabajar solo Orientado a
  objetos y no con objetos.

>Namespaces ayuda un poquito, mínimamente, pero
>ayuda.

>>Ultima recomendación:
>> Te decía que los NameSpaces no son peligrosos...
>> Verificá bien como funciona lo que estás migrando,
>>    pues los mas difícil de migrar de un Smalltalk a otro
>>    es que hay diferencias que son sutiles y afectan tanto
>>    perfomance como a veces son causales de fallas
>>    imprevistas.
>Ok, lo tendré en cuenta.

No se si desestimaste la opción de definir el NameSpace
  con el comportamiento de acceso...
Creo que es una solución "elegante" (de las lindas :)
  y que no te haría perder mucho tiempo.

Cuantas colisiones tenes en lo que estás portando?
Si podes, decinos de que porcentaje de nombres
  colisionados estamos hablando,como para darnos
  una idea de la gravedad del "problema" :-)
Si el porcentaje es alto me sorprendería, pero
  indica que está afectando de forma concreta el
  producto y en este aspecto me gustaría hacer un
  estudio de los NameSpaces.

gracias a vos!

hasta pronto,
Ale.




----- Original Message -----
From: "Chiara" <muralito@...>
To: <smalltalking@...>
Sent: Monday, July 17, 2006 11:00 PM
Subject: Re: [objetos] Re: NameSpacs en Squeak


Hola Alejandro, gracias por la respuesta y por la tentativa de solución.
Asimismo no comparto tu punto de vista con respecto a los Namespaces.

Los namespaces son valiosos para quienes entienden que
> es deseable aumentar la capacidad declarativa de la sintaxis
> de Smalltalk, para permitir declarar(de forma previa)
> una nominación mas específica que la dada por un
> solo nombre.
>

Totalmente de acuerdo en este punto. El namespace te da el contexto en el
que  se desenvuelve el nombre.

Es un hecho reciente en Smalltalk,
> y en realidad (en la práctica es)  innecesario;
>

A mi entender no es del todo así. Teóricamente si puede se innecesario ya
que la posibilidad de nombres para las clases es potencialmente infinita
:-). Pero a la hora de llevarlo a la práctica poder definir tu namespace es
algo que ayuda y más si se quiere hacer un desarrollo distribuido (en más de
una persona :)). imaginate si se desarrollan X módulos de forma
independiente, que tienen nombres en común como State o Type y que despues
se quieran unir. Obvio que se pueden modificar los nombres anteriores
anteponiendo el Namespace (NamespaceClase) pero es algo que "molesta" al
desarrollo y a mi entender perjudica la lectura del código, en definitica, a
mi entender no es práctico.

En comunidades mas libres, comola de Squeak, esta presión
> no existe; y esa es una de las razones (creo) por la que una utilidad
> que no sea necesaria en la práctica no está presente.
>

Me parece perfecto. Pero me gustaría que alguien hubiera solucionado este
"problema" :(.

En todo Squeak se observa lo contrario a presiones
> respecto del "estilo" y se valora mucho más la estética del
> resultado que la forma en que está logrado, su estabilidad
> e incluso su calidad.
>

mmmm no se a que te referís aca. calidad en base a que criterio? mi criterio
es el de programación "linda" y escalable, por eso me gusta el diseño en
objetos (aunque debo confesar que usaba Java :s) y en particular Smalltalk.ç

Por esta razón, creo que si encontrás en Squeak algo
> "parecido" a NameSpaces, serán restos de algo que ha
> desaparecido (luego de algunos ensayos para demostrar
> su inutilidad práctica real).
>

:-(

De vez en cuando en la lista de Squeak se gravita sobre
> este punto (en realidad sobre la problemática de la
> nominación dinámica; que es un tema más amplio y ambicioso).
> Cuando esto ocurre aparecen al menos dos reflexiones
> de forma recurrente:
> 1.- tener NameSpaces solo para nombres de objetos
> es una solución de corto plazo; pues en realidad lo útil
> sería poder extender el concepto a los mensajes (con lo
> que se complica mucho mas el tema).
>

este....

2.- que el naming sea estático (resuelto en durante la
> compilación) es algo inútil y solo resuelve las colisiones;
> es decir, no da servicio al sistema mismo, sino solo a las
> personas que lo escriben (declaran); por lo que no es un
> tema del sistema en si, sino de la sintaxis en que se expresa
> en texto... (si el sistema se construye con objetos, el
> problema desaparece, y se transforma en un tema del
> pasado)
>

No estoy de acuerdo. Muchos usan un argumento parecido (no es problema del
"sistema") para justificar la falta de bloques en Java. ERROR! el "sistema"
tendría que facilitar la programación y lograr que el programador se centre
en el qué y no en el cómo. Namespaces ayuda un poquito, mínimamente, pero
ayuda.


Ahora "poniéndome en tus zapatos", es decir.. tratando
> de ayudarte en la migración...
>

Gracias de nuevo.

Ultima recomendación:
> Te decía que los NameSpaces no son peligrosos...
> Verificá bien como funciona lo que estás migrando,
>    pues los mas difícil de migrar de un Smalltalk a otro
>    es que hay diferencias que son sutiles y afectan tanto
>    perfomance como a veces son causales de fallas
>    imprevistas.
>

Ok, lo tendré en cuenta.

suerte,
> Ale.
>

--
Saludos Chiara

"Peace cannot be kept by force; it can only be achieved by understanding."
Albert Einstein

Hola,

>   Que necesidad te fuerza a implementar lo mismo en MT ?
>   La respuesta es, que quiero aprender sobre MT y 3D,
> no encuentro mejor manera que hacer este trabajo.

Ambos a la vez? mmmm :-)

Creo que quizás sería mas simple lograr en
  Genesis3D+VisualSmalltalk lo que desees armar;
  y luego, uan vez bien eentendido como manejarte
  con Genesis3D, empezar a ver el tema de APIs
  en MT...
Quizás es mejor que hagas el acceso vía API de algunas
  librerías mas simples antes de Genesis3D; para evitar
  que se te presenten problemas por ambos lados...

>   Me inscribi a foros de Games para ver que se
> puede hacer con los engine OO, ya que para su
> comunicacion con otros lenguajes implemtan un
> mecanismo de Scripting  que no se como
> funciona realmente.

En el ámbito de desarrollo de juegos lo "mas avanzado"
  es scripting, es decir, incluir un interprete en el sistema
  de juego y así permitir que un "usuario" modifique
  escribiendo en lenguajes del tipo Basic, C o Java...
Esto es un gran avance con respecto a lo que había
  antes; y muchos desarrolladores de juegos lo festejan
  como si fuera lo máximo.
Incluso algunos engines tienen scripting OO!!!
  con los que podes lograr tanto como lo que puede
  lograrse con un PascalOO, "re"usando (en la forma
  de entender el término como NO lo entendemos
  aquí :) los componentes que exponen los diseñadores.

Toda analogía con el uso de un ambiente, termina
  dónde uno empezaba a buscarla :-)

Hace varios meses (1 o 2 años creo) envié a esta
  lista algunos links sobre el tema.

>   Vos me comentaste que lo ideal era hacer un API en C,
> estuve preguntando el los foros de C/C++ y nadie sabe
> como hacer esto.

Es lo que hacen los que trabajan con Cpuspus y desean
  que sus componentes sean usados desde C, Pascal,
  o Fortran...
En eso no hay ninguna particularidad relacionada con Smalltalk.
Como ejemplo... podes ver cualquier librería implementada
  en C++ y que expone una API tradicional, como OpenCV,
  o como la librería de partículas que uso junto con Genesis3D
   (que tenes en el image como ParticleProject)
   http://www.cs.unc.edu/~davemc/Particle
en dónde verás que pese a estar hecho en C++, se publica
  una API tradicional y así puede usarse como si fuera C.
Fijate en la implementación de ParticleDLL y las subclases
  de ParticleObject para ver como se usan en Smalltalk,
  y en los fuentes de la librería para ver como se logra
  el wrapper en C.

suerte,
Ale.


----- Original Message -----
From: "kikote gregoris" <kikogregoris@...>
To: <smalltalking@...>
Sent: Tuesday, July 18, 2006 10:18 AM
Subject: Re: [objetos] Help: Genesis3D


> Hola ALe
>
>   Todavía no consigo que funcione, pero no desespero.
>
>   Que necesidad te fuerza a implementar lo mismo en MT ?
>
>   La respuesta es, que quiero aprender sobre MT y 3D, no encuentro mejor
manera que hacer este trabajo.
>
>   En un futuro tenia pensado usar otro engine, como nebula 2 u otro.
>   El problema es que toda la nueva generacion de Engin3d esta desarrollada
en C++ y eso me complica la vida, mientras desarrollo este trabajo con
genesis3d estoy viendo de reojo otros alternativas mas modernas, pero como
te desia todos estan en C++ excepto el de Quake pero ademas de que la
licencia es astronomica (500000 $$) el motor es inentendible ya que hay una
licencia GNU y me descargue el codigo .
>
>   Tenes que ser un mago para entender como funciona la cosa y sin DOC
claro.
>   Me inscribi a foros de Games para ver que se puede hacer con los engine
OO, ya que para su comunicacion con otros lenguajes implemtan un mecanismo
de Scripting  que no se como funciona realmente.
>
>   Bueno cualquier cosa que puedas aportar te lo agradesco.
>
>   Vos me comentaste que lo ideal era hacer un API en C, estuve preguntando
el los foros de C/C++ y nadie sabe como hacer esto.
>   Buscando encontre como mapear una clase a una estructura y como hacer un
par de funciones en C para ejecutar los metodos de la clase, pero eso tiene
la desventaja que si la clase tiene miembros estaticos, el mapeo no funciona
por que estos miembros se guardan diferente en una clase.
>
>
>
>   saludos kiko
>
> "Alejandro F. Reimondo" <aleReimondo@...> escribió:
>   Hola kiko,
> Era a eso que me refería, pero veo que con cero esta bien...
> Fijate en el comment de GenesisEngine>>#render:with:time:
> pues allí dice algo que puede determinar la patología
> que estas sufriendo.
>
> Disculpame que pregunte... (no recuerdo si ya me lo dijiste)
> Que necesidad te fuerza a implementar lo mismo en MT ?
>
> hasta pronto,
> Ale.
>
>
>
> ----- Original Message -----
> From: "kikote gregoris" <kikogregoris@...>
> To: <smalltalking@...>
> Sent: Friday, July 14, 2006 11:36 AM
> Subject: Re: [objetos] Help: Genesis3D
>
>
> > Hola Ale
> >
> >   Esta es tu implementación del método que rendea todo.
> >   Si te referías al parámetro que le pasas a:
> >   # engine render: aWorld with: self camera time: 0"seconds".
> >   Como puedes ver es 0, si es que te referis a eso.
> >   Te aclaro que no se para que sirve este parámetro, ya que en la demo
que
> viene con genesis también le pasa 0
> >
> >
> >   render: aSpace in: aDevice for: aSpaceManager
> >               "Render the receiver's contents in aDevice."
> >
> >               | now elapsed aWorld engine seconds |
> >               rendering == true ifTrue: [ ^true ].
> >               aWorld := aSpace world.
> >               aWorld isNil ifTrue: [ ^true ].
> >               now := Time millisecondClockValue.
> >               elapsed := now - self lastRenderTime.
> >               elapsed < self minimumElapsedTime ifTrue: [ ^true ].
> >               self lastRenderTime: now.
> >               engine := aDevice engine.
> >               [ seconds := elapsed / 1000.0 ] on: ArithmeticError do: [
> ^true ].
> >               [          rendering := true.
> >                           [ aDevice renderStart
> >                             ifTrue: [
> >                                      self triggerEvent: #preRender:
with:
> seconds.
> >                                      (engine beginFrame: self camera)
> >                                      ifTrue: [
> >                                                  self triggerEvent:
> #startFrame: with: seconds.
> >                                                  self transform: aSpace
> at: seconds for: aSpaceManager.
> >                                                  self triggerEvent:
> #aboutToRender: with: seconds.
> >                                                  self
doNotDoTheFirstTime:
> [
> >                                                              engine
> render: aWorld with: self camera time: 0"seconds".
> >
> >                                                  ].
> >                                                  navigator notNil
ifTrue:
> [
> >                                                              navigator
> >
> overlay: aWorld seconds: seconds
> >
> for: aSpace in: engine
> >                                                  ].
> >                                                  self triggerEvent:
> #endFrame: with: seconds.
> >                                                  engine endFrame.
> >                                                  self triggerEvent:
> #postRender: with: seconds.
> >                                      ].
> >                                      aDevice renderStop.
> >                             ].
> >                           ] ensure: [ rendering := false ].
> >               ] value" evaluateWithoutInterrupts".
> >               ^trae.
> >
> >   Por ultimo, decir que estoy mas confundido que nunca, en la
> implementación que realice en VS pude crear GenesisFont y verlas, pero en
MT
> no pude, solo puedo ver el FrameRateCount y usar la función printf:at.
> >   No se, voy a seguir dandole manija a ver si sale algo mas.
> >
> >   Saludos kiko
> >
> >
> > "Alejandro F. Reimondo" <aleReimondo@...> escribió:  Si mal
> no recuerdo, al engine hay que pasarle (en cada render)
> > un indicador del tiempo de simulacion (es decir, cuanto hace que
> > no lo refrescas, en tics de simulación)...
> > Estas seguro de estar incrementando ese valor?
> > Quizas eso es lo que pasa, el engine peinsa que no paso
> > ningun tiempo desde que lo arrancaste y no hace una
> > actualización del buffer de rendering interno...
> > suerte,
> > Ale.
> >
> > ----- Original Message -----
> > From: "kikote gregoris" <kikogregoris@...>
> > To: <smalltalking@...>
> > Sent: Friday, July 07, 2006 11:13 AM
> > Subject: Re: [objetos] Help: Genesis3D
> >
> >
> > > Hola Ale
> > >
> > >
> > >   Cargue un actor y uso el mensaje #isActor:potentiallyVisibleWith:,
el
> > cual me retorna verdadero, pero no veo al actor.
> > >   Creía que podía ser un problema que tenga que ver con el tamaño del
> > actor, con lo cual me puse a escalarlo para ver que pasaba,pero nada.
> > >
> > >   Luego cargo un bitmap y uso el mensaje #isBitmapVisible, el cual me
> > retorna falso,
> > >    pero ya lo agregue y lo mostré con #displayBitmap:at:.
> > >
> > >   Alguna idea de lo que me pueda estar pasando????????
> > >
> > >   Saludos kiko
> > >
> > >
> > >  __________________________________________________
> > > Correo Yahoo!
> > > Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
> > > ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar
> >
> >
> >
> >
> > ---------------------------------
> >  Horóscopos, Salud y belleza, Chistes, Consejos de amor.
> >  El contenido más divertido para tu celular está en
> > Yahoo! Móvil
>
>
>
>
> ---------------------------------
>  Preguntá. Respondé. Descubrí.
>  Todo lo que querías saber, y lo que ni imaginabas,
>  está en Yahoo! Respuestas (Beta).
>  Probalo ya!

----- Original Message -----

From: kikote gregoris

To: smalltalking@...

Sent: Tuesday, July 18, 2006 10:18 AM

Subject: Re: [objetos] Help: Genesis3D

Hola ALe

 

Todavía no consigo que funcione, pero no desespero.

 

Que necesidad te fuerza a implementar lo mismo en MT ?

La respuesta es, que quiero aprender sobre MT y 3D, no encuentro mejor manera que hacer este trabajo.

 

En un futuro tenia pensado usar otro engine, como nebula 2 u otro.

El problema es que toda la nueva generacion de Engin3d esta desarrollada en C++ y eso me complica la vida, mientras desarrollo este trabajo con genesis3d estoy viendo de reojo otros alternativas mas modernas, pero como te desia todos estan en C++ excepto el de Quake pero ademas de que la licencia es astronomica (500000 $$) el motor es inentendible ya que hay una licencia GNU y me descargue el codigo .....

 

Hola kiko,
Era a eso que me refería, pero veo que con cero esta bien...
Fijate en el comment de GenesisEngine>>#render:with:time:
pues allí dice algo que puede determinar la patología
que estas sufriendo.

Disculpame que pregunte... (no recuerdo si ya me lo dijiste)
Que necesidad te fuerza a implementar lo mismo en MT ?

hasta pronto,
Ale.



----- Original Message -----
From: "kikote gregoris" <kikogregoris@...>
To: <smalltalking@...>
Sent: Friday, July 14, 2006 11:36 AM
Subject: Re: [objetos] Help: Genesis3D


> Hola Ale
>
>   Esta es tu implementación del método que rendea todo.
>   Si te referías al parámetro que le pasas a:
>   # engine render: aWorld with: self camera time: 0"seconds".
>   Como puedes ver es 0, si es que te referis a eso.
>   Te aclaro que no se para que sirve este parámetro, ya que en la demo que
viene con genesis también le pasa 0
>
>
>   render: aSpace in: aDevice for: aSpaceManager
>               "Render the receiver's contents in aDevice."
>
>               | now elapsed aWorld engine seconds |
>               rendering == true ifTrue: [ ^true ].
>               aWorld := aSpace world.
>               aWorld isNil ifTrue: [ ^true ].
>               now := Time millisecondClockValue.
>               elapsed := now - self lastRenderTime.
>               elapsed < self minimumElapsedTime ifTrue: [ ^true ].
>               self lastRenderTime: now.
>               engine := aDevice engine.
>               [ seconds := elapsed / 1000.0 ] on: ArithmeticError do: [
^true ].
>               [          rendering := true.
>                           [ aDevice renderStart
>                             ifTrue: [
>                                      self triggerEvent: #preRender: with:
seconds.
>                                      (engine beginFrame: self camera)
>                                      ifTrue: [
>                                                  self triggerEvent:
#startFrame: with: seconds.
>                                                  self transform: aSpace
at: seconds for: aSpaceManager.
>                                                  self triggerEvent:
#aboutToRender: with: seconds.
>                                                  self doNotDoTheFirstTime:
[
>                                                              engine
render: aWorld with: self camera time: 0"seconds".
>
>                                                  ].
>                                                  navigator notNil ifTrue:
[
>                                                              navigator
>
overlay: aWorld seconds: seconds
>
for: aSpace in: engine
>                                                  ].
>                                                  self triggerEvent:
#endFrame: with: seconds.
>                                                  engine endFrame.
>                                                  self triggerEvent:
#postRender: with: seconds.
>                                      ].
>                                      aDevice renderStop.
>                             ].
>                           ] ensure: [ rendering := false ].
>               ] value" evaluateWithoutInterrupts".
>               ^trae.
>
>   Por ultimo, decir que estoy mas confundido que nunca, en la
implementación que realice en VS pude crear GenesisFont y verlas, pero en MT
no pude, solo puedo ver el FrameRateCount y usar la función printf:at.
>   No se, voy a seguir dandole manija a ver si sale algo mas.
>
>   Saludos kiko
>
>
> "Alejandro F. Reimondo" <aleReimondo@...> escribió:  Si mal
no recuerdo, al engine hay que pasarle (en cada render)
> un indicador del tiempo de simulacion (es decir, cuanto hace que
> no lo refrescas, en tics de simulación)...
> Estas seguro de estar incrementando ese valor?
> Quizas eso es lo que pasa, el engine peinsa que no paso
> ningun tiempo desde que lo arrancaste y no hace una
> actualización del buffer de rendering interno...
> suerte,
> Ale.
>
> ----- Original Message -----
> From: "kikote gregoris" <kikogregoris@...>
> To: <smalltalking@...>
> Sent: Friday, July 07, 2006 11:13 AM
> Subject: Re: [objetos] Help: Genesis3D
>
>
> > Hola Ale
> >
> >
> >   Cargue un actor y uso el mensaje #isActor:potentiallyVisibleWith:, el
> cual me retorna verdadero, pero no veo al actor.
> >   Creía que podía ser un problema que tenga que ver con el tamaño del
> actor, con lo cual me puse a escalarlo para ver que pasaba,pero nada.
> >
> >   Luego cargo un bitmap y uso el mensaje #isBitmapVisible, el cual me
> retorna falso,
> >    pero ya lo agregue y lo mostré con #displayBitmap:at:.
> >
> >   Alguna idea de lo que me pueda estar pasando????????
> >
> >   Saludos kiko
> >
> >
> >  __________________________________________________
> > Correo Yahoo!
> > Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
> > ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar
>
>
>
>
> ---------------------------------
>  Horóscopos, Salud y belleza, Chistes, Consejos de amor.
>  El contenido más divertido para tu celular está en
> Yahoo! Móvil

Hola gente

  Quizas es off toppic pero siempre tuve la duda si el
generador de codigo y/o compilador c del smalltalk/X
era tambien gratuito,no se porque me parece que no lo
es,por favor que alguien que sepa lo aclare
saludos

  MDC
  --- Félix Madrid <fmadrid@...> escribió:

> Hola Mariano,
>
> Te cuento que recientemente empece a trabajar para
> eXept (la empresa detras
> del Smalltalk/X).
>
> Si bien mi experiencia con el ST/X es solo de un
> mes, puedo comentarte
> ciertas caracteristicas:
>
> - tiene alta compatibilidad con VW (por ejemplo, en
> 2 semanas han migrado
> GLORP)
> - el GUI builder es similar al de VW (si estas
> acostumbrado al uso de Aspect
> o ValueHolder no vas a notar ninguna diferencia)
> - la performance es tan buena como VW y en el caso
> que necesites ejecuciones
> con tiempo critico, se puede insertar inline C code
> dentro de los metodos en
> ST
> - tengo entendido que se lo esta usando en
> aplicaciones industriales en
> tiempo real.
> - el entorno de desarrollo es muy bueno. Tiene
> muchisimos enhacements en
> menus, codePane y demases artilugios a los que los
> ST estamos acostumbrados.
> Salvo el Inspector, que quiza necesite una
> actualizacion.
>
> dentro de los puntos debiles que he notado pueden
> encontrarse:
>
> - la falta de un code management incorporado.
> Actualmente el repositorio de
> codigo se realiza a traves de cualquier CVS
> (Tourtuise, etc...)
> - el hecho que no haya una gran comunidad de
> usuarios atras, como en Dolphin
> o VW
>
> Existe la posibilidad de acordar un contrato para
> obtener soporte,
> correccion de bugs y las ultimas versiones
> instantaneamente (por el momento,
> desconozco detalles de costos).
>
> Sera un placer responder o comentarle a Claus
> Gittinger cualquiera de tus
> dudas/preguntas.
>
> Saludos
>
> Felix
>
>
> On 7/17/06, Mariano Wahlmann
> <mariano.wahlmann@...> wrote:
> >
> >  Hola gente, nuevamente escribo para consultarles
> algo a uds. que son
> > personas que ya andaron por los caminos de
> smalltalk.
> > La pregunta en esta oportunidad es referia a
> Smalltalk/X, quería saber
> > si alguien tenía referencias y quería saber los
> puntos fuertes/débiles
> > de dicha implementación de smalltalk.
> > Empece a trabajar en una empresa desarrollando en
> smalltalk, y al
> > principio empece en Squeak, pero casi al toque
> tuve que descartarlo por
> > problemas de performance, y dificultad para
> desarrollar aplicaciones
> > comerciales, ya se quizas algunos piensen que los
> problemas de
> > performance son porque estoy obviando algo, o no
> estoy haciendo las
> > cosas del todo bien, los problemas de performance
> existen en Squeak,
> > trabajo con grandes volumenes de datos y
> procesamientos que involucran
> > mucho cómputo, y los millisegundos que existen
> entre squeak y
> > visualworks en una operación quizas no sea gran
> cosa, pero cuando la
> > operacion se repite millones y millones de veces
> (laburando con
> > algorítmos que son N * N, o N log N), las
> diferencias son muy notorias.
> > Luego después de squeak pase a visualworks (con el
> que estoy laburando
> > actualmente) y estoy muy conforme con el ambiente,
> las prestaciones y
> > los resultados, el único problema es justamente la
> licencia que me
> > parece un afano literalmente (por lo del 9%, no
> tanto por los 700U$S).
> > Entonces buscando llegue a stx parece ser un
> ambiente apto para
> > aplicaciones comerciales y completamente gratuito,
> es por eso que les
> > pregunto a uds. cuales son los pro y las contras.
> > Coincido como ya dijo Alejandro alguna vez que hay
> que agarrar un
> > ambiente y hacerlo propio ,quizas se la etapa que
> estoy atravesando.
> > Espero sus comentarios, gracias.
> >
> >
>




_________________________________________________________
Horóscopos, Salud y belleza, Chistes, Consejos de amor:
el contenido más divertido para tu celular está en Yahoo! Móvil.
Obtenelo en http://movil.yahoo.com.ar

Hola gente, nuevamente escribo para consultarles algo a uds. que son
personas que ya andaron por los caminos de smalltalk.
La pregunta en esta oportunidad es referia a Smalltalk/X, quería saber
si alguien tenía referencias y quería saber los puntos fuertes/débiles
de dicha implementación de smalltalk.
Empece a trabajar en una empresa desarrollando en smalltalk, y al
principio empece en Squeak, pero casi al toque tuve que descartarlo por
problemas de performance, y dificultad para desarrollar aplicaciones
comerciales, ya se quizas algunos piensen que los problemas de
performance son porque estoy obviando algo, o no estoy haciendo las
cosas del todo bien, los problemas de performance existen en Squeak,
trabajo con grandes volumenes de datos y procesamientos que involucran
mucho cómputo, y los millisegundos que existen entre squeak y
visualworks en una operación quizas no sea gran cosa, pero cuando la
operacion se repite millones y millones de veces (laburando con
algorítmos que son N * N, o N log N), las diferencias son muy notorias.
Luego después de squeak pase a visualworks (con el que estoy laburando
actualmente) y estoy muy conforme con el ambiente, las prestaciones y
los resultados, el único problema es justamente la licencia que me
parece un afano literalmente (por lo del 9%, no tanto por los 700U$S).
Entonces buscando llegue a stx parece ser un ambiente apto para
aplicaciones comerciales y completamente gratuito, es por eso que les
pregunto a uds. cuales son los pro y las contras.
Coincido como ya dijo Alejandro alguna vez que hay que agarrar un
ambiente y hacerlo propio ,quizas se la etapa que estoy atravesando.
Espero sus comentarios, gracias.

Hola!,

> Hola, hace poco comenze a desarrollar en Squeak (migré desde
> Smalltalk), lo que no encontré es como tener diferentes Namespaces, vi
> un paquete que andaba dando vueltas, pero no anda :-(.
>me corrijo:...
...
Ah! no se entendía bien... como era que
  habías visto un paquete que andaba dando vueltas
...sin andar  :-)

[lo que sigue es fuera de chiste :) ]
Los namespaces son valiosos para quienes entienden que
  es deseable aumentar la capacidad declarativa de la sintaxis
  de Smalltalk, para permitir declarar(de forma previa)
  una nominación mas específica que la dada por un
solo nombre.
Así es como llega a Visual Works, luego de un camino
  promovido por quienes han hecho esfuerzos en definir
  el ANSI Smalltalk.
Es un hecho reciente en Smalltalk,
  y en realidad (en la práctica es)  innecesario;
  pero de mucha aceptación (por presiones externas
  a Smalltalk).
Como varias cosas que han ocurrido en los últimos años
  con Visual Works, "los usuarios" no pueden evitar el usarlo
  pues se les hace inevitable el hacerlo (pues se han reformulado
  los frameworks para que sea incomodo el no prestar
  atención a los nameSpaces).
En comunidades mas libres, comola de Squeak, esta presión
  no existe; y esa es una de las razones (creo) por la que una utilidad
  que no sea necesaria en la práctica no está presente.
En todo Squeak se observa lo contrario a presiones
  respecto del "estilo" y se valora mucho más la estética del
  resultado que la forma en que está logrado, su estabilidad
  e incluso su calidad.
Por esta razón, creo que si encontrás en Squeak algo
  "parecido" a NameSpaces, serán restos de algo que ha
  desaparecido (luego de algunos ensayos para demostrar
  su inutilidad práctica real).
De vez en cuando en la lista de Squeak se gravita sobre
  este punto (en realidad sobre la problemática de la
  nominación dinámica; que es un tema más amplio y ambicioso).
Cuando esto ocurre aparecen al menos dos reflexiones
  de forma recurrente:
1.- tener NameSpaces solo para nombres de objetos
  es una solución de corto plazo; pues en realidad lo útil
  sería poder extender el concepto a los mensajes (con lo
  que se complica mucho mas el tema).
2.- que el naming sea estático (resuelto en durante la
  compilación) es algo inútil y solo resuelve las colisiones;
  es decir, no da servicio al sistema mismo, sino solo a las
  personas que lo escriben (declaran); por lo que no es un
  tema del sistema en si, sino de la sintaxis en que se expresa
  en texto... (si el sistema se construye con objetos, el
  problema desaparece, y se transforma en un tema del
  pasado)

Ahora "poniéndome en tus zapatos", es decir.. tratando
  de ayudarte en la migración...
Los NameSpaces no presentan riesgos importantes al
  momento de migrar, es decir, con solo un poco de atención
  podes resolverlo sin introducir patologías sutiles "por accidente".
Al migrar intentá evaluar si realmente hay colisiones de nombres,
  es decir, si los NameSpaces realmente sirvieron para algo;
  por lo general ocurre que no sirven (es decir, las colisiones son
  del 0% - o menores al 5 por mil)
En ese caso, directamente elimina los NameSpaces y reemplaza
  concatenando el nombre en conflicto con el del NameSpace
  original.

Si queres hacer algo "menos agresivo", podes crear, como
  globales, tantos objetos como NameSpaces tengas;
  eliminá de los textos fuentes los "::" (o la notación usada para
  denominar un nameSpace) cambiándolo por un espacio;
  e implementá mensajes (en Mayúsculas) que devuelven
  el objeto global que estaba dentro del paquete.
Así la referencia  MiEspacio::MiClase
  se transforma en MiEspacio
  que es un objeto global, que implementa el mensaje
  MiClase devolviendo la clase MiClase (si no había colisión)
  o la clase de nombre MiEspacioMiClase (si había colisión).

Espero te sea de utilidad, y que esta respuesta no llegue
  muy tarde (es posible que ya hayas empezado a eliminar
  los NameSpaces al darte cuenta de algunas de las cosas
  que comento aquí :)

Ultima recomendación:
  Te decía que los NameSpaces no son peligrosos...
  Verificá bien como funciona lo que estás migrando,
    pues los mas difícil de migrar de un Smalltalk a otro
    es que hay diferencias que son sutiles y afectan tanto
    perfomance como a veces son causales de fallas
    imprevistas.

suerte,
Ale.







----- Original Message -----
From: "Chiara" <muralito@...>
To: <smalltalking@...>
Sent: Sunday, July 16, 2006 1:52 PM
Subject: [objetos] Re: NameSpacs en Squeak


> Hola, hace poco comenze a desarrollar en Squeak (migré desde
> Smalltalk), lo que no encontré es como tener diferentes Namespaces, vi
> un paquete que andaba dando vueltas, pero no anda :-(.

me corrijo: migré desde VisualWorks. Y realmente no encuentro alguna
implementación de Namespace en squeak :-(. Encontre este paquete
http://map.squeak.org/package/f88f4752-c4a5-42bf-a613-f7d2a4f48cff
pero no funciona correctamente

> ¿Alguién que me presta su experiencia?

--
Saludos Chiara

"Peace cannot be kept by force; it can only be achieved by understanding."
Albert Einstein


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