Juan,
Mi comentario fue porque conozco al menos
  dos personas del interior que deseaban ir
  a la reunión.
Para ellos es cansador ir y venir solo y en el día.
Quizás si se pudiera organizar mejor la estadía
  sea mas motivante y agradable el viajar hasta
  aquí.
En otras épocas hemos hecho presentaciones
  en el interior (recuerdo la que nos acompañaste...
  o fue mas de una? ), pero esta ves estamos
  pensando en una reunión para "hablar de lo
  que nos gusta" sin intensión de dar un servicio
  a gente que no conoce de lo que hablamos aquí.
hasta pronto,
Ale.

----- Original Message -----
From: "Juan" <juanlb@...>
To: <smalltalking@...>
Sent: Wednesday, January 31, 2007 12:00 PM
Subject: Re: [objetos] RV: reunion de febrero


Hola Leo
¿Dónde es la reunión que están gestando?
Me tomaron desprevenido y me creí que era en la ciudad de Buenos Aires
Saludos
Juan


   ----- Original Message -----
   From: Alejandro F. Reimondo
   To: smalltalking@...
   Sent: Wednesday, January 31, 2007 8:55 AM
   Subject: Re: [objetos] RV: reunion de febrero


   Quizás un sábado a la mañana es mejor si alguien quiere viajar para la
   reunión...
   Si es así, p/f escribirle a Leo para que lo considere y/o vean si son mas
   de uno, si es posible/mejor reservar una habitación juntos en un hotel
   si no quieren viajar a las apuradas y aprovechan mejor el viaje...
   Ale.

   ----- Original Message -----
   From: "Juan" <juanlb@...>
   To: <smalltalking@...>
   Sent: Wednesday, January 31, 2007 1:03 AM
   Subject: Re: [objetos] RV: reunion de febrero

   Hola

   Yo estoy interesado. Si es un dìa de semana prefiero los viernes (por
   ejemplo el viernes 9) porque de lunes a jueves termino tarde. O sino un
   sábado o domingo.

   Saludos
   Juan

   ----- Original Message -----
   From: Leonardo De Marco
   To: smalltalking@...
   Sent: Tuesday, January 30, 2007 3:11 PM
   Subject: [objetos] RV: reunion de febrero

   ----------------------------------------------------------
   --
   De: Leonardo De Marco
   Enviado el: Martes, 30 de Enero de 2007 14:57
   Para: smalltalking@...
   Asunto: reunion de febrero

   Gente:

   Propongo hacer la reunion en la semana del 5, diganme que dia prefieren.
   Los anotados hasta ahora son:
   -Jose Gregoris
   -Ale Reimondo
   -Leonardo De Marco
   -Esteban Robles Luna
   -Juan Martin Chiaradia

   Acuerdensen de traer lo que quieran ese dia para mostrar al resto, si hay
   alguien mas interesado mandeme un mail asi lo agrego a la lista.

   Saludos,
   Leo

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

   No virus found in this incoming message.
   Checked by AVG Free Edition.
   Version: 7.5.432 / Virus Database: 268.17.15/659 - Release Date:
   30/01/2007 09:31 a.m.






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


   No virus found in this incoming message.
   Checked by AVG Free Edition.
   Version: 7.5.432 / Virus Database: 268.17.15/659 - Release Date:
30/01/2007 09:31 a.m.

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

From: Alejandro F. Reimondo

To: smalltalking@...

Sent: Wednesday, January 31, 2007 8:55 AM

Subject: Re: [objetos] RV: reunion de febrero

Quizás un sábado a la mañana es mejor si alguien quiere viajar para la
reunión...
Si es así, p/f escribirle a Leo para que lo considere y/o vean si son mas
de uno, si es posible/mejor reservar una habitación juntos en un hotel
si no quieren viajar a las apuradas y aprovechan mejor el viaje...
Ale.

----- Original Message -----
From: "Juan" <juanlb@fibertel.com.ar>
To: <smalltalking@gruposyahoo.com.ar>
Sent: Wednesday, January 31, 2007 1:03 AM
Subject: Re: [objetos] RV: reunion de febrero

Hola

Yo estoy interesado. Si es un dìa de semana prefiero los viernes (por
ejemplo el viernes 9) porque de lunes a jueves termino tarde. O sino un
sábado o domingo.

Saludos
Juan

----- Original Message -----
From: Leonardo De Marco
To: smalltalking@gruposyahoo.com.ar
Sent: Tuesday, January 30, 2007 3:11 PM
Subject: [objetos] RV: reunion de febrero

----------------------------------------------------------
--
De: Leonardo De Marco
Enviado el: Martes, 30 de Enero de 2007 14:57
Para: smalltalking@gruposyahoo.com.ar
Asunto: reunion de febrero

Gente:

Propongo hacer la reunion en la semana del 5, diganme que dia prefieren.
Los anotados hasta ahora son:
-Jose Gregoris
-Ale Reimondo
-Leonardo De Marco
-Esteban Robles Luna
-Juan Martin Chiaradia

Acuerdensen de traer lo que quieran ese dia para mostrar al resto, si hay
alguien mas interesado mandeme un mail asi lo agrego a la lista.

Saludos,
Leo

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

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.15/659 - Release Date:
30/01/2007 09:31 a.m.

---

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.15/659 - Release Date: 30/01/2007 09:31 a.m.

Leo,
Es posible llevar el material en un CD?
hay una maquina con lectora de CD para
  poder mostrar algo?
Sería bueno, a mi entender ir organizando
  los temas y horarios/orden acordados
  para cada tema. no?
Ale.

----- Original Message -----
From: "Leonardo De Marco" <leo@...>
To: <smalltalking@...>
Sent: Tuesday, January 30, 2007 3:11 PM
Subject: [objetos] RV: reunion de febrero


>   _____
>
> De: Leonardo De Marco
> Enviado el: Martes, 30 de Enero de 2007 14:57
> Para: smalltalking@...
> Asunto: reunion de febrero
>
>
> Gente:
>
> Propongo hacer la reunion en la semana del 5, diganme que dia prefieren.
> Los anotados hasta ahora son:
> -Jose Gregoris
> -Ale Reimondo
> -Leonardo De Marco
> -Esteban Robles Luna
> -Juan Martin Chiaradia
>
> Acuerdensen de traer lo que quieran ese dia para mostrar al resto, si hay
> alguien mas interesado mandeme un mail asi lo agrego a la lista.
>
>
> Saludos,
> Leo
>

Quizás un sábado a la mañana es mejor si alguien quiere viajar para la
reunión...
Si es así, p/f escribirle a Leo para que lo considere y/o vean si son mas
  de uno, si es posible/mejor reservar una habitación juntos en un hotel
  si no quieren viajar a las apuradas y aprovechan mejor el viaje...
Ale.

----- Original Message -----
From: "Juan" <juanlb@...>
To: <smalltalking@...>
Sent: Wednesday, January 31, 2007 1:03 AM
Subject: Re: [objetos] RV: reunion de febrero


Hola

Yo estoy interesado. Si es un dìa de semana prefiero los viernes (por
ejemplo el viernes 9) porque de lunes a jueves termino tarde. O sino un
sábado o domingo.

Saludos
Juan

   ----- Original Message -----
   From: Leonardo De Marco
   To: smalltalking@...
   Sent: Tuesday, January 30, 2007 3:11 PM
   Subject: [objetos] RV: reunion de febrero




----------------------------------------------------------------------------
--
   De: Leonardo De Marco
   Enviado el: Martes, 30 de Enero de 2007 14:57
   Para: smalltalking@...
   Asunto: reunion de febrero


   Gente:

   Propongo hacer la reunion en la semana del 5, diganme que dia prefieren.
   Los anotados hasta ahora son:
         -Jose Gregoris
         -Ale Reimondo
         -Leonardo De Marco
         -Esteban Robles Luna
         -Juan Martin Chiaradia


   Acuerdensen de traer lo que quieran ese dia para mostrar al resto, si hay
alguien mas interesado mandeme un mail asi lo agrego a la lista.


   Saludos,
   Leo




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


   No virus found in this incoming message.
   Checked by AVG Free Edition.
   Version: 7.5.432 / Virus Database: 268.17.15/659 - Release Date:
30/01/2007 09:31 a.m.

---

De: Leonardo De Marco
Enviado el: Martes, 30 de Enero de 2007 14:57
Para: smalltalking@gruposyahoo.com.ar
Asunto: reunion de febrero

Gente:

 

Propongo hacer la reunion en la semana del 5, diganme que dia prefieren.

Los anotados hasta ahora son:

-Jose Gregoris

-Ale Reimondo

-Leonardo De Marco

-Esteban Robles Luna

-Juan Martin Chiaradia

 

Acuerdensen de traer lo que quieran ese dia para mostrar al resto, si hay alguien mas interesado mandeme un mail asi lo agrego a la lista.

 

 

Saludos,

Leo

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

From: Leonardo De Marco

To: smalltalking@...

Sent: Tuesday, January 30, 2007 3:11 PM

Subject: [objetos] RV: reunion de febrero

---

De: Leonardo De Marco
Enviado el: Martes, 30 de Enero de 2007 14:57
Para: smalltalking@gruposyahoo.com.ar
Asunto: reunion de febrero

Gente:

 

Propongo hacer la reunion en la semana del 5, diganme que dia prefieren.

Los anotados hasta ahora son:

-Jose Gregoris

-Ale Reimondo

-Leonardo De Marco

-Esteban Robles Luna

-Juan Martin Chiaradia

 

Acuerdensen de traer lo que quieran ese dia para mostrar al resto, si hay alguien mas interesado mandeme un mail asi lo agrego a la lista.

 

 

Saludos,

Leo

---

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.15/659 - Release Date: 30/01/2007 09:31 a.m.

Hola Chiara,

>>  De esta forma ponemos un método indicando
>>   que el receptor NO entiende ese mensaje...
>Es real el problema que planteas, la jerarquía te induce
> a que pienses que el método es entendido por la instancia,

El mensaje... no el método (lo apunto por lo que sigue...)

> pero, si bien esta solución es más "elegante" que el
> #shouldNotImplement sigue teniendo el problema
> de que en la clase Array hay un método #add: por
> lo que el simple programador solamente basándose
> en el protocolo de la clase, podría intentar usar
> este #add: obteniendo un error.

La presencia de un método (o su ausencia) en la clase
  no tiene relación con los mensajes que entiende/noEntiende
  un objeto que es instancia de esa clase.
Es muy bueno pensar que es así (muy simple) e incluso es
  conveniente enseñar/mostrar, al comienzo, que hay una relación
  unívoca entre mensajes y métodos.. pero a un nivel un
  poco mas avanzado (no introductorio) siempre debe
  aclararse que, en rigor, no es verdad eso que se dijo
  al comienzo :-)

En el trabajo y en el estudio/uso de Smalltalk aparecen
  oportunidades para darse cuenta de lo que estamos hablando.

Asociar a una "falla" en la jerarquía o a una limitación
  en la jerarquía (por ser simple) es lo que a todos nos viene
  a la mente cuando vemos estas cosas, pero a mi me ha
  pasado con el tiempo que uno toma una perspectiva
  que nos permite analizar de forma menos dura lo que
  encontramos (y que ha sido usado por años).

Con respecto al "protocolo"... en mi Smalltalk no existe esa
  clase (Protocolo), por lo que no existe el problema
  que se plantearía si existiera :-)
  (lo digo con animosidad, porque en caso de planetarse,
  por ejemplo "interfaces", vería muy correcto lo que comentás)

>Desde mi perspectiva el problema esta en una mal subclasificación, y
>si existen casos en los que se tiene que recurrir a esta técnica
>planteada por Ale es porque la jerarquía de clases obtenida no es la
>correcta y de seguro hay algún problema de diseño.

No estaremos tomando muy en serio la jerarquía?
(así iba a comenzar mis comentarios a lo que había aportado
  Juan, pero por alguna razón no lo puse, prefiriendo que la
  charla se diera por el rumbo que tomaste, Chiara)

>Si puede ser útil en casos en los que ya se tiene todo un sistema
> funcionando y es costoso reestructurar toda la jerarquía
> (rediseñar), aunque el "es costoso" a la larga resulta "mas barato"
> ya que se va a contar con un sistema más comprensible
> y mejor diseñado.

El problema se desprende, a mi entender, de la realidad de que
  una clase no es atómica, es decir, se dá, porque un objeto se
  define con mas de una faceta (satisface más de una óptica);
  en esas situaciones, ocurre que una herencia muy refinada
  y estratégicamente dispuesta/descompuesta es mucho mas
  compleja de entender que una simple, con un numero mínimo
  de "parches".
Los parches relajan la formalidad que presenta una jerarquía
  robusta y permiten retrasar el entendimiento en profundidad
  de una problemática cuando no se la ve.
El ver la problemática, muchas veces, implica el tener idea
  de como "mejorar" la situación con un cambio (casi siempre
  inocente), el efectuar el cambio y poder vivir un tiempo las
  consecuencias nos permite ir entrando mas en el problema.
Y en varios puntos en los que me ha pasado lo que comento
  aquí, me encuentro hoy siendo mas permisivo luego de
  haber intentado alternativas que me parecían muy limpias
  (e incluso, en algunas situaciones, después de ver que uno
  debería entonces modificar tanto que crea un frankestein
  exponiendo otros inconvenientes).
A veces la limpieza de un fino diseño es tan estéril que
  no nos es tan útil (en la práctica) como el consenso con
  lo común.

Ojo! con esto no quiero desestimar tus comentarios,
  Chiara, sino dejar en claro que a veces, uno observa una
  coherencia con la tradición solo al poder experimentar
  algunas alternativas "mejores"...

hasta pronto,
Ale.



----- Original Message -----
From: "Chiara" <muralito@...>
To: <smalltalking@...>
Sent: Friday, January 19, 2007 6:39 PM
Subject: Re: [objetos] Array: La pregunta boluda del verano


>  >La nobleza de Smalltalk permite que esa violación quede
>  > perfectamente expuesta:
>
>  >    ArrayedCollection>>add: newObject
>  >     "ArrayedCollections cannot implement add:."
>  >     self shouldNotImplement
>
>  Esta implementación hace a un Array entender el mensaje #add:
>   y creo que ese es el punto objetable y que a todos nos suena mal...
>  Es "incorrecto" que una colección de tamaño fijo ENTIENDA #add:
>  Esto parece contraponerse con el hecho de que exista
>   un método que implemente el mensaje #add:
>  Es decir.... nos induce (incorrectamente) a pensar que
>   si una clase implementa un método para un mensaje,
>   implica que las instancias de esa clase ENTIENDEN
>   el mensaje...
>
>  Entonces..., creo yo, el problema se resuelve
>   implementando un método que indique que
>   el mensaje NO es entendido...

>  Cómo se resuelve el problema ?
>
>  !Array methods!
>  add: anObject
>      " Add anObject to the receiver. Answer anObject. "
>
>  ^self doesNotUnderstand: (Message new
>              receiver: self selector: #add:
>              arguments: (Array with: anObject))! !
>
>  De esta forma ponemos un método indicando
>   que el receptor NO entiende ese mensaje...

Es real el problema que planteas, la jerarquía te induce a que pienses
que el metodo es entendido por la instancia, pero, si bien esta
solución es más "elegante" que el #shouldNotImplement sigue teniendo
el problema de que en la clase Array hay un metodo #add: por lo que el
simple programador solamente basandose en el protocolo de la clase,
podría intentar usar este #add: obteniendo un error.

Desde mi perspectiva el problema esta en una mal subclasificación, y
si existen casos en los que se tiene que recurrir a esta técnica
planteada por Ale es porque la jerarquía de clases obtenida no es la
correcta y de seguro hay algún problema de diseño. Si puede ser útil
en casos en los que ya se tiene todo un sistema funcionando y es
costoso reestructurar toda la jerarquia (rediseñar), aunque el "es
costoso" a la larga resulta "mas barato" ya que se va a contar con un
sistema más comprensible y mejor diseñado.

>  hasta pronto,
>  Ale.


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

A todos los que les pueda interesar, aqui reenvio la palabra oficial.

Una vez mas , inmensas gracias a todos.

Pueden jugar remotamente en http://201.212.99.13:8088/ usando Firefox
unicamente desde su lado.

Todo no podran hacer, por ahora, pero si ayudan ....

Ojitoo !!

Estoy trackeando los IP, pero saque la autenticacion ya que solo tenia la
lista de la gente inscripta en SqueakMap.

Si no anda , mandar mail para que pueda inventar alguna excusa creible :=)

Horario de atencion al público, aproximadamente 09:00 a 20:00 GMT

------ Mensaje reenviado
> De: Ralph Johnson <johnson@...>
> Responder a: "Discussion about development of Squeak 3.10"
> <v3dot10@...>
> Fecha: Thu, 18 Jan 2007 06:14:59 -0600
> Para: "Discussion about development of Squeak 3.10"
> <v3dot10@...>
> Asunto: [V3dot10] my plans for alpha and beyond
>
> My plans for the alpha release is to use the image that Edgar has
> made.  So, you really ought to take a look at it and let us know if
> you have any objections.  The image is basically 3.9 with some
> packages removed.  In addition, I will make the testing policy that
> all submitted changes should pass all the existing tests, i.e. "tests
> should be green".
>
> I was hoping to have a testing server for the alpha release, but I
> just found out that the student working on it has not progressed very
> far.  So, we'll have to do that later.  But at least we can start with
> a simple testing policy.
>
> My goal is to drastically componentize Squeak.  I've looked over
> Pavel's KernelImage, which makes Morphic a loadable component, and
> like it a lot.  This is the future of 3.10.  My goal is to set up a
> process so that we can accept a change as big as this.  It is a very
> big change!  But the advantage of componentizing Squeak like this is
> that it makes it much easier for people to make alternative UIs, to
> make minimal images without Morphic, and so on.  To be successful, we
> have to be able to pull all the pieces together to make an image
> compatible with what we have now.  The process has to make this not
> only possible, but easy.  That is hard!
>
> Suppose we split Squeak into components.  It is not enough to test a
> change to a single component.  You have to test changes in one
> component against all the other components.  Right now, people want to
> put their changes in the image because they know that if their code is
> "second class" then people will change the image and break their code.
>  If they can put their code in the image then there is more of a
> chance that people will change the image in ways that keeps their code
> working.  If we want to split Squeak into components, we have to
> change this way of doing things.  We have to have the rule that
> changes to Squeak must not only keep all the tests in the image green,
> they have to keep all the tests in the components green.  We could do
> this testing by hand if there are only two or three components, but
> there will be hundreds of them, and so we will have to have a test
> server to check that all the tests are green.
>
> So, the release team will be responsible for the image and for a set
> of official components.  We need a name for these components;
> "supported", "official", "approved", "core".  None of these names are
> perfect.  I'd like to find a perfect name for them.  The test server
> will have to test combinations of components.  It doesn't need to test
> an exponential number of combinations.  For starters, it could test
> each component individually and then test all of them together.
> Except that sometime two components will not be compatible with each
> other (they are alternative implementations of Date, for example) and
> so a little exponential growth will occur.  We can handle it if there
> are only two or three cases, but not if there are a hundred.
>
> i have not said what a "component" is or what a "change" is.  I'll
> deal with that in my next message.
>
> -Ralph
> _______________________________________________
> V3dot10 mailing list
> V3dot10@...
> http://lists.squeakfoundation.org/mailman/listinfo/v3dot10

------ Fin del mensaje reenviado







__________________________________________________
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

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

From: Chiara

To: smalltalking@...

Sent: Friday, January 19, 2007 6:39 PM

Subject: Re: [objetos] Array: La pregunta boluda del verano

> >La nobleza de Smalltalk permite que esa violación quede
> > perfectamente expuesta:
>
> > ArrayedCollection>>add: newObject
> > "ArrayedCollections cannot implement add:."
> > self shouldNotImplement
>
> Esta implementación hace a un Array entender el mensaje #add:
> y creo que ese es el punto objetable y que a todos nos suena mal...
> Es "incorrecto" que una colección de tamaño fijo ENTIENDA #add:
> Esto parece contraponerse con el hecho de que exista
> un método que implemente el mensaje #add:
> Es decir.... nos induce (incorrectamente) a pensar que
> si una clase implementa un método para un mensaje,
> implica que las instancias de esa clase ENTIENDEN
> el mensaje...
>
> Entonces..., creo yo, el problema se resuelve
> implementando un método que indique que
> el mensaje NO es entendido...

> Cómo se resuelve el problema ?
>
> !Array methods!
> add: anObject
> " Add anObject to the receiver. Answer anObject. "
>
> ^self doesNotUnderstand: (Message new
> receiver: self selector: #add:
> arguments: (Array with: anObject))! !
>
> De esta forma ponemos un método indicando
> que el receptor NO entiende ese mensaje...

Es real el problema que planteas, la jerarquía te induce a que pienses
que el metodo es entendido por la instancia, pero, si bien esta
solución es más "elegante" que el #shouldNotImplement sigue teniendo
el problema de que en la clase Array hay un metodo #add: por lo que el
simple programador solamente basandose en el protocolo de la clase,
podría intentar usar este #add: obteniendo un error.

Desde mi perspectiva el problema esta en una mal subclasificación, y
si existen casos en los que se tiene que recurrir a esta técnica
planteada por Ale es porque la jerarquía de clases obtenida no es la
correcta y de seguro hay algún problema de diseño. Si puede ser útil
en casos en los que ya se tiene todo un sistema funcionando y es
costoso reestructurar toda la jerarquia (rediseñar), aunque el "es
costoso" a la larga resulta "mas barato" ya que se va a contar con un
sistema más comprensible y mejor diseñado.

> hasta pronto,
> Ale.

--
Saludos Chiara

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

---

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.0/639 - Release Date: 18/01/2007 06:47 p.m.

>  >La nobleza de Smalltalk permite que esa violación quede
>  > perfectamente expuesta:
>
>  >    ArrayedCollection>>add: newObject
>  >     "ArrayedCollections cannot implement add:."
>  >     self shouldNotImplement
>
>  Esta implementación hace a un Array entender el mensaje #add:
>   y creo que ese es el punto objetable y que a todos nos suena mal...
>  Es "incorrecto" que una colección de tamaño fijo ENTIENDA #add:
>  Esto parece contraponerse con el hecho de que exista
>   un método que implemente el mensaje #add:
>  Es decir.... nos induce (incorrectamente) a pensar que
>   si una clase implementa un método para un mensaje,
>   implica que las instancias de esa clase ENTIENDEN
>   el mensaje...
>
>  Entonces..., creo yo, el problema se resuelve
>   implementando un método que indique que
>   el mensaje NO es entendido...

>  Cómo se resuelve el problema ?
>
>  !Array methods!
>  add: anObject
>      " Add anObject to the receiver. Answer anObject. "
>
>  ^self doesNotUnderstand: (Message new
>              receiver: self selector: #add:
>              arguments: (Array with: anObject))! !
>
>  De esta forma ponemos un método indicando
>   que el receptor NO entiende ese mensaje...

Es real el problema que planteas, la jerarquía te induce a que pienses
que el metodo es entendido por la instancia, pero, si bien esta
solución es más "elegante" que el #shouldNotImplement sigue teniendo
el problema de que en la clase Array hay un metodo #add: por lo que el
simple programador solamente basandose en el protocolo de la clase,
podría intentar usar este #add: obteniendo un error.

Desde mi perspectiva el problema esta en una mal subclasificación, y
si existen casos en los que se tiene que recurrir a esta técnica
planteada por Ale es porque la jerarquía de clases obtenida no es la
correcta y de seguro hay algún problema de diseño. Si puede ser útil
en casos en los que ya se tiene todo un sistema funcionando y es
costoso reestructurar toda la jerarquia (rediseñar), aunque el "es
costoso" a la larga resulta "mas barato" ya que se va a contar con un
sistema más comprensible y mejor diseñado.

>  hasta pronto,
>  Ale.


--
Saludos Chiara

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

Hola Juan, lista,

>Lo digo porque Collection implementa el #add: y Array desciende
> por subclasificación de Collection. A mí me parece que debería
> bastar ese conocimiento y que no habría porqué tener ninguna
> duda de que Array responde satisfactoriamente al #add:.

>El hecho de que el #add: no se pueda utilizar para los Arrays viola
> el polimorfismo porque no puedo poner un Array donde se
> esperaba una Collecion.

>La nobleza de Smalltalk permite que esa violación quede
> perfectamente expuesta:

>    ArrayedCollection>>add: newObject
>     "ArrayedCollections cannot implement add:."
>     self shouldNotImplement

Esta implementación hace a un Array entender el mensaje #add:
  y creo que ese es el punto objetable y que a todos nos suena mal...
Es "incorrecto" que una colección de tamaño fijo ENTIENDA #add:
Esto parece contraponerse con el hecho de que exista
  un método que implemente el mensaje #add:
Es decir.... nos induce (incorrectamente) a pensar que
  si una clase implementa un método para un mensaje,
  implica que las instancias de esa clase ENTIENDEN
  el mensaje...

Entonces..., creo yo, el problema se resuelve
  implementando un método que indique que
  el mensaje NO es entendido...

A mi entender, la implementacion de #add:
  como  "self implementedBySubclass" (o como se
  use en el dialecto que estamos trabajando)
  es insatisfactoria, por dos razones:
1.- no resuelve el verdadero problema que plantea
  la herencia (indicar que las instancias NO entienden
  el mensaje, aunque hereden de Collection).
2.- (en el caso de shouldNotImplement) sugiere que
  las subclases no deben implementar el mensaje (cosa que
  no puede decirse de antemano, sin conocer que
  subclases habrá a futuro).

Cómo se resuelve el problema ?

!Array methods!
add: anObject
     " Add anObject to the receiver. Answer anObject. "

     ^self doesNotUnderstand: (Message new
             receiver: self selector: #add:
             arguments: (Array with: anObject))! !

De esta forma ponemos un método indicando
  que el receptor NO entiende ese mensaje...

El método debería ser implementado en el lugar
  adecuado para que esto se propague a las
  colecciones de tamaño fijo, en los casos,
  dónde esta característica esta distinguida
  en al jerarquía.

Esta forma de resolver esta situación (en el #add:
  y otros lugares) no se ha usado (según yo se)
  en ningún Smalltalk de los "conocidos". :-)

Que ventaja presenta esta forma de implementarlo?

Que en caso de activarse el método, la excepción/error
  que se genera es la que esperaríamos del hecho de
  enviar un mensaje que el receptor no entiende.
En algunos lugares he visto este problema usado
  en criticas a la herencia simple y como sustento
  de mecanismos "alternativos" sin conocer este truco
  que aquí comento y no reconociendo además las consecuencias
  de jerarquías múltiples o del fraccionamiento del comportamiento.

hasta pronto,
Ale.







----- Original Message -----
From: "Juan" <juanlb@...>
To: <smalltalking@...>
Sent: Wednesday, January 17, 2007 11:35 AM
Subject: Re: [objetos] Array: La pregunta boluda del verano


Hola Sergio
¿En qué Smalltalk un Array acepta el mensaje #add:?
En los que yo utilizo (Dolphin y VisualWorks) el mensaje #add: queda vedado
para todas las ArrayedCollection.

Ahora que estoy consultando el libro de Smalltalk-80, confirmo que la
prohibición del add: es parte del standard. Concretamente dice
"ArrayedCollections are fixed-length so add: is disallowed".

Teniendo en cuenta eso se podría ajustar tu solución definiendo soloNumeros
como OrderedCollection (que sí acepta el add:)
     soloNumeros := OrderedCollection new: (anArray size * 3).

y luego del resto del trabajo retornar la conversión de esa
OrderedCollection a Array

     ^soloNumeros asArray


Otra alternativa sería utilizar un array como destino de un WriteStream:
     wstream := (Array new: anArray size * 3) writeStream.
     anArray do: [ :objeto |
     soloNumeros nextPutAll: objeto dameTodosTusNumerosPapito.
].
^wstream contents.

Volviendo al tema del #add: supongo que te confundiste, tal vez también bajo
el efecto del relax veraniego.

Pero creo que un poco el diseño de la jerarquía de Collection es responsable
de que cometamos ese tipo de error. Yo lo padecí varias veces.

Lo digo porque Collection implementa el #add: y Array desciende por
subclasificación de Collection. A mí me parece que debería bastar ese
conocimiento y que no habría porqué tener ninguna duda de que Array responde
satisfactoriamente al #add:.

El hecho de que el #add: no se pueda utilizar para los Arrays viola el
polimorfismo porque no puedo poner un Array donde se esperaba una Collecion.

La nobleza de Smalltalk permite que esa violación quede perfectamente
expuesta:

     ArrayedCollection>>add: newObject
      "ArrayedCollections cannot implement add:."

      self shouldNotImplement


Y el shouldNotImplement puede ser considerado como una subclase que no es
verdaderamente polimórfica:

     shouldNotImplement
      "The class of the receiver is unable to provide an implementation of a
message in
      the protocol of one of its superclasses. Generate an exception to this
effect.

      This error will be experienced when an attempt is made to use
inappropriate
      superclass protocol against a subclass which is not a true sub-type
(e.g.
      SortedCollection is not a true sub-type of OrderedCollection, as it
does
      not support the indexed access method #at:put:."

Saludos
Juan


   ----- Original Message -----
   From: Sergio Fedi
   To: smalltalking@...
   Sent: Wednesday, January 17, 2007 2:42 AM
   Subject: Re: [objetos] Array: La pregunta boluda del verano


   > Tengo un problema para generar un Array de otro Array.
   > Pongo un ejemplo para que sea más fácil entender.
   >
   > Tengo un Array de 12 objetos, esos objetos contiene 3 enteros en
distintas variables.
   > Esos enteros son índices para construir un maya poligonal.
   > El tema es que quiero generar un Array con esos índices todos juntos, es
decir un array de enteros nada más, para sacarme de encima esos objetos que
contenía el Array original
   >
   > El tema es que no puedo generar el puto Array con los enteros.
   > No se, debe ser el sol de verano que me afecta el cerebro.
   >
   > Alguna idea ¿?.

   Si entendi bien:

   ProblemasBoludosDelVerano>>dameSoloLosNumerosDe: anArray

   | soloNumeros |
   soloNumeros := Array new: (anArray size * 3).
   anArray do: [ :objeto |
   soloNumeros addAll: objeto dameTodosTusNumerosPapito.
   ].
   ^soloNumeros

   Si no tenes un metodo que te devuelva todos los numeros, reemplaza la
linea:

   soloNumeros addAll: objeto dameTodosTusNumerosPapito.

   por:

   soloNumeros add: objeto numero1.
   soloNumeros add: objeto numero2.
   soloNumeros add: objeto numero3.

   Espero haber entendido (y resuelto) bien el problema.





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


   No virus found in this incoming message.
   Checked by AVG Free Edition.
   Version: 7.5.432 / Virus Database: 268.16.13/632 - Release Date:
16/01/2007 04:36 p.m.

On 1/18/07, Sergio Fedi <sergio.fedi@...> wrote:
>
>
>
>
>
>
> >  Otro problema que surje es el uso de #shouldNotImplement,
>  >  particularmente yo lo uso solo en clases abstractas para indicar que
>  >  el método es abstracto (aunque para esto tendría que ser:
>  >  #mustBeImplemented :-)), pero aca está usado con otra finalidad,
>  >  justamente la finalidad que el nombre indica :-)...
>
>  Tenia entendido que en esos casos se usa el #subclassResponsibility

Jeje si es verdad, yo lo uso así... el verano nos abombo a todos me parece jajaj



--
Saludos Chiara

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

>  Otro problema que surje es el uso de #shouldNotImplement,
>  particularmente yo lo uso solo en clases abstractas para indicar que
>  el método es abstracto (aunque para esto tendría que ser:
>  #mustBeImplemented :-)), pero aca está usado con otra finalidad,
>  justamente la finalidad que el nombre indica :-)...

Tenia entendido que en esos casos se usa el #subclassResponsibility

> Pero creo que un poco el diseño de la jerarquía de  Collection es responsable
de que cometamos ese tipo de error. Yo lo padecí  varias veces.

Es real que la gerarquia de Collection no es todo lo intuitiva que
podría ser. pero  sigue siendo mejor que la de muchos lenguajes :-).

> Lo digo porque Collection implementa el #add:  y Array desciende por
subclasificación de Collection. A mí me parece que debería  bastar ese
conocimiento y que no habría porqué tener ninguna duda de que Array  responde
satisfactoriamente al #add:.
>
> El hecho de que el #add: no se pueda  utilizar para los Arrays viola el 
polimorfismo porque no puedo poner un Array donde se esperaba una  Collecion.

La cuestion aca es: Array es subclase de Collection?
no creo que sea cuestión de polimorfismo, en todo caso un array
responde a un #add: levantando un error que es lo que se espera que
suceda, el polimorfismo anda bien :-).
El problema es que el Array debería no responder a un #add: con lo que
dejaría de ser subclase de Collection.
Otro problema que surje es el uso de #shouldNotImplement,
particularmente yo lo uso solo en clases abstractas para indicar que
el método es abstracto (aunque para esto tendría que ser:
#mustBeImplemented :-)), pero aca está usado con otra finalidad,
justamente la finalidad que el nombre indica :-)...

Se podría reestructurar la jerarquía de Collection de una forma mas
"prolija" e "intuitiva" y no creo que sea mucho trabajo...

> Y el shouldNotImplement puede ser considerado como  una subclase que no es
verdaderamente polimórfica:
>
>      shouldNotImplement
>      "The class of the receiver is  unable to provide an implementation of a
message in
>       the protocol of one of its superclasses. Generate an exception to this 
effect.
>
>      This error will be  experienced when an attempt is made to use
inappropriate
>       superclass protocol against a subclass which is not a true sub-type 
(e.g.
>      SortedCollection is not a true sub-type of  OrderedCollection, as it does
>      not support the  indexed access method #at:put:."

De vuelta, la "nobleza de smalltalk" dice justamente lo que yo decía arriba:

"This error will be  experienced when an attempt is made to use
inappropriate    superclass protocol against a subclass which is not a
true sub-type"

> Saludos
> Juan

--
Saludos Chiara

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

On 1/17/07, Chiara <muralito@gmail.com> wrote:

No se si entendí lo que quisiste preguntar, pero aca generas un array con todos los indices...

arrayDeIndices := (arrayDeObjetos inject: OrderedCollection new into:[:col :obj | col addAll: obj]) asArray

Yo tambien pifie, ya que el addAll: retorna la coleccion agregada (obj) con lo que despues de la primer iteracion del inject:into: col pasa a ser un array y se rompe, así que hay que arreglarlo:

arrayDeIndices :=
(
arrayDeObjetos
   inject: OrderedCollection new
   into:[:col :obj | col addAll: obj. col]
) asArray

Esto funciona bien.

On 1/16/07, kikote gregoris <kikogregoris@yahoo.com.ar > wrote:

Hola Gente

 

 

Tengo un problema para generar un Array de otro Array.

Pongo un ejemplo para que sea más fácil entender.

 

Tengo un Array de 12 objetos, esos objetos  contiene 3 enteros en distintas variables.

Esos enteros son índices para  construir un maya poligonal.

El tema es que quiero generar un Array con esos índices todos juntos, es decir un array de enteros nada más,   para sacarme de encima esos objetos que contenía el Array original

 

El tema es que no puedo generar el puto Array con los enteros.

No se, debe ser el sol de verano que me afecta el cerebro.

 

Alguna idea ¿?.

 

Saludos kiko

---

Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
Probalo ya!

--
Saludos Chiara

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

--
Saludos Chiara

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

> Hola Sergio
> ¿En qué Smalltalk un Array acepta el mensaje  #add:?
> En los que yo utilizo (Dolphin y VisualWorks) el  mensaje #add: queda vedado
para todas las ArrayedCollection.

Si, si, le pifié fierisimo.

Y encima habia una mejor forma de hacerlo, con el inject:into:

Y bueno, a pregunta boluda del verano, respuesta boluda :D

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

From: Sergio Fedi

To: smalltalking@...

Sent: Wednesday, January 17, 2007 2:42 AM

Subject: Re: [objetos] Array: La pregunta boluda del verano

> Tengo un problema para generar un Array de otro Array.
> Pongo un ejemplo para que sea más fácil entender.
>
> Tengo un Array de 12 objetos, esos objetos contiene 3 enteros en distintas variables.
> Esos enteros son índices para construir un maya poligonal.
> El tema es que quiero generar un Array con esos índices todos juntos, es decir un array de enteros nada más, para sacarme de encima esos objetos que contenía el Array original
>
> El tema es que no puedo generar el puto Array con los enteros.
> No se, debe ser el sol de verano que me afecta el cerebro.
>
> Alguna idea ¿?.

Si entendi bien:

ProblemasBoludosDelVerano>>dameSoloLosNumerosDe: anArray

| soloNumeros |
soloNumeros := Array new: (anArray size * 3).
anArray do: [ :objeto |
soloNumeros addAll: objeto dameTodosTusNumerosPapito.
].
^soloNumeros

Si no tenes un metodo que te devuelva todos los numeros, reemplaza la linea:

soloNumeros addAll: objeto dameTodosTusNumerosPapito.

por:

soloNumeros add: objeto numero1.
soloNumeros add: objeto numero2.
soloNumeros add: objeto numero3.

Espero haber entendido (y resuelto) bien el problema.

---

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.16.13/632 - Release Date: 16/01/2007 04:36 p.m.

> Tengo un problema para generar un Array de otro Array.
> Pongo un ejemplo para que sea más fácil entender.
>
> Tengo un Array de 12 objetos, esos objetos  contiene 3 enteros en distintas
variables.
> Esos enteros son índices para  construir un maya poligonal.
> El tema es que quiero generar un Array con esos índices todos juntos, es decir
un array de enteros nada más,  para sacarme de encima esos objetos que contenía
el Array original
>
> El tema es que no puedo generar el puto Array con los enteros.
> No  se, debe ser el sol de verano que me afecta el cerebro.
>
> Alguna idea ¿?.

Si entendi bien:

ProblemasBoludosDelVerano>>dameSoloLosNumerosDe: anArray

| soloNumeros |
soloNumeros := Array new: (anArray size * 3).
anArray do: [ :objeto |
  soloNumeros addAll: objeto dameTodosTusNumerosPapito.
].
^soloNumeros

Si no tenes un metodo que te devuelva todos los numeros, reemplaza la linea:

  soloNumeros addAll: objeto dameTodosTusNumerosPapito.

por:

  soloNumeros add: objeto numero1.
  soloNumeros add: objeto numero2.
  soloNumeros add: objeto numero3.

Espero haber entendido (y resuelto) bien el problema.

Hola gente!

Solo algunos comentarios rapidos...

Las ideas no estan en nuestras cabezas solamente... tambien estan en
las otras cabezas. Y para que se difundan, creo firmemente que deben
ser difundidas sin necesidad de hacer una
hermeneutica/interpretacion de ambiguedades de lo que la otra cabeza
tenia encerrada.

Si bien el ambiente se trata en otros ambitos, no queda siempre
claro el mapeo de algunas de tus posturas con los otros ambitos. Y
traer ideas de un ambito a otro, sin una explicacion clara, se da
para el abuso (basta tomar el tema de la evolucion (termino que
Darwin no utilizo) como se lo lleva de cualquier forma a cualquier
lado....ejemplo clarisimo, el darwinismo social de Spencer)

A Aristoteles, que al parecer no escribio nada, lo salvo lo escrito
por algun diligente "alumno". En cambio, no se, de Gorgias solo
tenemos la critica de Platon. Y del bueno de Parmenides.... bueno,
apenas lo que alguno atino a repetir en su momento....

No veo de la misma forma "ser servil a las ideas". Hay que conocer
las ideas, o conceptos, o intuiciones del otro, no aceptarlas
(tampoco rechazarlas porque si). Pero para conocer las ideas,
conceptos o intuiciones, el otro tiene que expresarlas claramente.
La lucha contra la ambiguedad es evitable. El dialogo es imposible,
si los dos no se expresan, usando algun lenguaje mas o menos
conveniente.

El escribir un texto, no invalida el dialogo. Solo lleva el dialogo
a otro nivel. Y creo que beneficia al autor (recuerdo al bueno de
Richard Feynmann "si no podemos explicarlo, es que no lo entendemos"
no es la frase exacta, espero haber captado el sentido), y aunque no
sea asi, beneficia o ayuda a los demas, que creo que es importante.

No hace falta que lo escribas solo, pero si seria bueno que
colabores con la escritura, supongo que varios integrantes de la
lista podrian colaborar....

Bueno, recuperandome de un locro.... nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/
http://www.ajlopez.net/

--- En smalltalking@..., "Alejandro F. Reimondo"
<aleReimondo@...> escribió:
>
> Hola Angel, buena gente de la lista,
>
> >Gracias Alejandro, por los enlaces, ya había pasado por algunos,
no
> >por otros. Conozco de tu predica desde hace años, y es monumental
> >trabajo que has llevado a cabo, aunque disiento en algunos puntos
> >que no veo tan importantes en la creación de software.
>
> Muchas gracias por tus palabras!
> Concuerdo contigo que a veces hacemos hincapié sobre puntos
>  que no son muy importantes, y que a veces llegamos a
>  apreciaciones extremas sobre puntos que quizás no
>  preocupan/molestan de la misma manera a todas las personas.
> Solo estamos hablando :-)
> Hacer smalltalking es hablar de cosas sin importancia,
>  hacer una charla que puede ser muy eufórica, pero en
>  el fondo despreocupada de las consecuencias que
>  pudiera generar :-)
>
> >Igualmente insistiría en algo que hasta ahora insinue: habria que
> >poner varias de esas presentaciones, en un lenguaje de texto, tal
> >vez acompaniados de graficos, es la forma (me parece, una
opinion),
> >para difundir mas la idea, explicarla, para los que no puedan ir a
> >una reunion.
>
> Entiendo a que te referís y varias (para no decir muchas) son
>  las personas que me han comentado lo mismo.
> El mayor motivante que tengo (en lo personal) para NO hacerlo
>  esta dado por el reconocimiento que tengo hacia todos los
>  que lo han hecho ya, en distintas áreas (casi nadie en
informática,
>  pero confío en que solo es cuestión de tiempo...).
> Es muchísimo el material que se ha escrito sobre los limites del
>  encapsulamiento (reduccionismo o como queramos llamar
>  a la no consideración de los sistemas abiertos) e incluso
>  creo que ha sido escrito por gente con mucha mas dedicación
>  que la que yo pudiera tener para comunicar (la idea de
>  ambiente, por ejemplo).
> Los resultados de esos trabajos (y la inmensa energía puesta
>  en tratar la problemática de ambiente sin formalizarla) son, a mi
>  entender, mucho mas pobres que los resultados (pobres) que
>  he tenido comunicando oralmente las ideas en términos de
>  sistemas de información.
> Esto no me pone contento, pero si me anima a no invertir
>  energía en dónde veo que otros no han podido generar
>  resultados satisfactorios (o al menos no tratar de hacerlo
>  de la misma forma).
>
> Dicho esto, dejame aclarar un punto, que creo que se nos está
>  escapando y para mi es muy importante...
> El escribir un texto es muy útil a quien puede leerlo, pero de
>  un valor escaso para quien lo escribe, comparado con el
>  valor que tiene un diálogo.
> Por varios años he aprovechado la invitación de amigos
>  (jefes de cátedra y ayudantes) a participar de clases
>  y debates en T.O. (y Smalltalk) en la mayoría de las
>  universidades de Buenos Aires y algunas del interior;
>  gracias a eso, aprendí a sacar frutos de las inquietudes
>  de quienes son vírgenes en el tema o que no están aún
>  muy ligados por la propia experiencia.
> Luego de eso, la formación de grupos de interés me fue
>  de mucha utilidad para tener relación con gente que
>  aprendía/debatía por períodos mayores a un cuatrimestre/semestre;
>  y esto me fue de mucha utilidad para poder elaborar ideas
>  de forma mas robusta (creo) que la que hubiera logrado
>  por reflexiones conmigo mismo o dadas solo por mis
>  experiencias laborales.
> También he buscado el diálogo con referentes en el tema
>  en otros ámbitos relacionados con lo ambiental/loAbierto
>  (en medio ambiente con Carlos Galano y otros,
>  en la política y social, x ejm. con Marta Maffei
>  y Teresita Malalán; entre otros), algunos de ellos
>  han escrito libros y me han comentado sobre los resultados
>  de hacerlo y que medios creen convenientes en
>  para una mejor difusión/aplicación de estas ideas.
>  http://www.fundacionecosur.org.ar/instit.asp
>
> El diálogo es bidireccional y ambas partes se enriquecen (si
>  saben sacarle frutos y si es noble la búsqueda del diálogo).
>  Además de ser bidireccional es instantánea, permite a las
>  personas compartir un tema como si fuera un viaje juntos,
>  cosa que no se logra ni siquiera con el chat.
>
> >Particularmente a mi, me gusta mucho la discusion por email,
porque
> >permite eso: bajar a texto la idea. La imagen acompania, la
> >experiencia tambien, pero creo que todo eso se puede acompaniar de
> >explicacion de texto. Pero en algun momento, podria bajarse todo
eso
> >a texto ordenado. El email tambien tiene limitaciones: termina
> >siendo un dialogo desordenado, donde tal vez los unicos que
avanzan
> >son los dos o tres que activamente participan (siempre y cuando se
> >hayan puesto de acuerdo en los terminos, y crean que están
hablando
> >de lo mismo, sino pasa la gran pregunta Elvio "estamos hablando de
> >lo mismo?"), donde hay que buscar aca y alla un trozo de
informacion
> >que falta en un mensaje.
>
> Si estuviéramos en una mesa de café estaríamos hablando de lo
mismo.
> No hay lugar a desincronizaciones.
> Se usan los gestos, y hasta el tocar al otro, si el que habla mira
>  para adentro y no escucha en tiempo real...
>
> >La reunion fisica tiene sus limitaciones: no todos pueden ir, no
> >todo se entiende "enseguida", no todo se retiene, no hay
> >espacio/tiempo para discutir o pensar y rebatir o digerir....
>
> Las reuniones son hechas para quienes pueden ir.
> No es conveniente no hacer reuniones porque "la mayoría" no pueda
ir.
>  (por otra parte: la mayoría de qué? de esta lista?
>  es pobre a mi entender acotar nuestra actividad a la lista,
>  creo que tenemos mas para dar que escribirnos x mail)
> Nuestras reuniones son formuladas de forma tal de garantizar
>  el disfrute de la charla si son al menos dos personas :-)
> [che... todo esto dicho con la mejor onda...]
>
> > Yo si fuera a una reunion con David Hume, o Noam Chomsky,
> > o Stephen Jay Gould, apenas captaria algo de lo que quisieron
> > decir, por ejemplo.
>
> Si, exacto, por eso intentamos hacer reuniones frecuentes.
> Es muy común que uno entienda cosas distintas a medida
>  que ha podido hacer sus propias experiencias.
> Es interesante cómo las personas me dicen a
>  menudo: "ahora entiendo lo que decías sobre xxxxxxxx
>  hace un año!!!... entonces no entendía nada!"
>  y se sorprenden mucho cuando les respondo:
>  "yo dije lo mismo que ahora"
>  (esto me sucedió con varias personas e incluso con
>  las mismas personas varias veces, sobre los mismos puntos)
>
> Creo que esto también ocurre con los libros. Reconozco
>  que la mayoría de los libros que he leído (los que aún no he
tirado)
>  los he leído varias veces, y me agrada muchísimo releerlos
>  para entrar en la misma trama y reinventar/explorar ese
>  espacio imaginario que se genera al leerlos en lugares que
>  se leen distinto de las veces anteriores, pero se tratan
>  de la misma trama... el mismo cuento.
> Con este rollo quiero decir, que por usarse el lenguaje hablado,
>  no se pierde este tipo de oportunidades de reencontrarse con
>  el pasado cuando uno esta aprendiendo, incluso, creo que
>  con reuniones periódicas, se alienta mas a rehacer "el cuento"
>  en grupo, dándole además cuerpo a una organización (Smalltalking)
>  que nos contiene/identifica y no nos deja solos frente a la
pantalla
>  (que no llega a ser siquiera un espejo).
>
> >Asi, que para cuando un libro, Alejandro?
>
> No creo que escriba un libro, seguramente lo harán otros.
>
> >(Otro si: creo mas eficiente, en terminos de alcance, el expresar
la
> >idea, que simplemente invitar a la vivencia de la idea.... la
forma
> >zen de difusion sera interesante y fuerte, pero creo que muestra
sus
> >limitaciones)
>
> No todos somos serviles a las ideas...
> (podríamos hablar mas de esto, que creo, es el punto
>  en el que más divergemos... si tenes ganas...)
>
> >Noten por ejemplo a Martin Fowler: www.martinfowler.com. El podria
> >haberse desaganitado haciendo presentaciones y reuniones, y nunca
> >hubiera llegado a difundir sus ideas de la forma en la que llego
si
> >no fuera por el libro con sus colaboradores, y su magnifico web
> >site. Lo mismo con Eric Evans.
>
> "sus ideas" ? :-)
> Las ideas que están en el libro ya no son suyas, sino del libro.
> No podemos disfrutar un conjunto de palabras escritas,
>  solo las ideas que juegan en nuestra cabeza.
> Ese juego es el que tiene gusto a disfrute.
> El diálogo con uno mismo, masticando las ideas,
>  reconforta, pero no lo disfruto tanto como cuando
>  lo abro hacia otro mientras lo miro a la cara.
>
> >A Aristóteles lo salvo alguien que paso en limpio lo que
decia... :-)
>
> A que te referís con "lo salvo" ?
> Quizás te referís a que alguien "salvo" sus ideas...
>  apreciación que no comparto, pues creo que las ideas
>  no necesitan de estar instanciadas, ni representadas en un
soporte.
>
> Para despedirme... un poquito de Smalltalk...
>
> ^1 abrazo
> Ale.
>

Hola Angel, buena gente de la lista,

>Gracias Alejandro, por los enlaces, ya había pasado por algunos, no
>por otros. Conozco de tu predica desde hace años, y es monumental
>trabajo que has llevado a cabo, aunque disiento en algunos puntos
>que no veo tan importantes en la creación de software.

Muchas gracias por tus palabras!
Concuerdo contigo que a veces hacemos hincapié sobre puntos
  que no son muy importantes, y que a veces llegamos a
  apreciaciones extremas sobre puntos que quizás no
  preocupan/molestan de la misma manera a todas las personas.
Solo estamos hablando :-)
Hacer smalltalking es hablar de cosas sin importancia,
  hacer una charla que puede ser muy eufórica, pero en
  el fondo despreocupada de las consecuencias que
  pudiera generar :-)

>Igualmente insistiría en algo que hasta ahora insinue: habria que
>poner varias de esas presentaciones, en un lenguaje de texto, tal
>vez acompaniados de graficos, es la forma (me parece, una opinion),
>para difundir mas la idea, explicarla, para los que no puedan ir a
>una reunion.

Entiendo a que te referís y varias (para no decir muchas) son
  las personas que me han comentado lo mismo.
El mayor motivante que tengo (en lo personal) para NO hacerlo
  esta dado por el reconocimiento que tengo hacia todos los
  que lo han hecho ya, en distintas áreas (casi nadie en informática,
  pero confío en que solo es cuestión de tiempo...).
Es muchísimo el material que se ha escrito sobre los limites del
  encapsulamiento (reduccionismo o como queramos llamar
  a la no consideración de los sistemas abiertos) e incluso
  creo que ha sido escrito por gente con mucha mas dedicación
  que la que yo pudiera tener para comunicar (la idea de
  ambiente, por ejemplo).
Los resultados de esos trabajos (y la inmensa energía puesta
  en tratar la problemática de ambiente sin formalizarla) son, a mi
  entender, mucho mas pobres que los resultados (pobres) que
  he tenido comunicando oralmente las ideas en términos de
  sistemas de información.
Esto no me pone contento, pero si me anima a no invertir
  energía en dónde veo que otros no han podido generar
  resultados satisfactorios (o al menos no tratar de hacerlo
  de la misma forma).

Dicho esto, dejame aclarar un punto, que creo que se nos está
  escapando y para mi es muy importante...
El escribir un texto es muy útil a quien puede leerlo, pero de
  un valor escaso para quien lo escribe, comparado con el
  valor que tiene un diálogo.
Por varios años he aprovechado la invitación de amigos
  (jefes de cátedra y ayudantes) a participar de clases
  y debates en T.O. (y Smalltalk) en la mayoría de las
  universidades de Buenos Aires y algunas del interior;
  gracias a eso, aprendí a sacar frutos de las inquietudes
  de quienes son vírgenes en el tema o que no están aún
  muy ligados por la propia experiencia.
Luego de eso, la formación de grupos de interés me fue
  de mucha utilidad para tener relación con gente que
  aprendía/debatía por períodos mayores a un cuatrimestre/semestre;
  y esto me fue de mucha utilidad para poder elaborar ideas
  de forma mas robusta (creo) que la que hubiera logrado
  por reflexiones conmigo mismo o dadas solo por mis
  experiencias laborales.
También he buscado el diálogo con referentes en el tema
  en otros ámbitos relacionados con lo ambiental/loAbierto
  (en medio ambiente con Carlos Galano y otros,
  en la política y social, x ejm. con Marta Maffei
  y Teresita Malalán; entre otros), algunos de ellos
  han escrito libros y me han comentado sobre los resultados
  de hacerlo y que medios creen convenientes en
  para una mejor difusión/aplicación de estas ideas.
  http://www.fundacionecosur.org.ar/instit.asp

El diálogo es bidireccional y ambas partes se enriquecen (si
  saben sacarle frutos y si es noble la búsqueda del diálogo).
  Además de ser bidireccional es instantánea, permite a las
  personas compartir un tema como si fuera un viaje juntos,
  cosa que no se logra ni siquiera con el chat.

>Particularmente a mi, me gusta mucho la discusion por email, porque
>permite eso: bajar a texto la idea. La imagen acompania, la
>experiencia tambien, pero creo que todo eso se puede acompaniar de
>explicacion de texto. Pero en algun momento, podria bajarse todo eso
>a texto ordenado. El email tambien tiene limitaciones: termina
>siendo un dialogo desordenado, donde tal vez los unicos que avanzan
>son los dos o tres que activamente participan (siempre y cuando se
>hayan puesto de acuerdo en los terminos, y crean que están hablando
>de lo mismo, sino pasa la gran pregunta Elvio "estamos hablando de
>lo mismo?"), donde hay que buscar aca y alla un trozo de informacion
>que falta en un mensaje.

Si estuviéramos en una mesa de café estaríamos hablando de lo mismo.
No hay lugar a desincronizaciones.
Se usan los gestos, y hasta el tocar al otro, si el que habla mira
  para adentro y no escucha en tiempo real...

>La reunion fisica tiene sus limitaciones: no todos pueden ir, no
>todo se entiende "enseguida", no todo se retiene, no hay
>espacio/tiempo para discutir o pensar y rebatir o digerir....

Las reuniones son hechas para quienes pueden ir.
No es conveniente no hacer reuniones porque "la mayoría" no pueda ir.
  (por otra parte: la mayoría de qué? de esta lista?
  es pobre a mi entender acotar nuestra actividad a la lista,
  creo que tenemos mas para dar que escribirnos x mail)
Nuestras reuniones son formuladas de forma tal de garantizar
  el disfrute de la charla si son al menos dos personas :-)
[che... todo esto dicho con la mejor onda...]

> Yo si fuera a una reunion con David Hume, o Noam Chomsky,
> o Stephen Jay Gould, apenas captaria algo de lo que quisieron
> decir, por ejemplo.

Si, exacto, por eso intentamos hacer reuniones frecuentes.
Es muy común que uno entienda cosas distintas a medida
  que ha podido hacer sus propias experiencias.
Es interesante cómo las personas me dicen a
  menudo: "ahora entiendo lo que decías sobre xxxxxxxx
  hace un año!!!... entonces no entendía nada!"
  y se sorprenden mucho cuando les respondo:
  "yo dije lo mismo que ahora"
  (esto me sucedió con varias personas e incluso con
  las mismas personas varias veces, sobre los mismos puntos)

Creo que esto también ocurre con los libros. Reconozco
  que la mayoría de los libros que he leído (los que aún no he tirado)
  los he leído varias veces, y me agrada muchísimo releerlos
  para entrar en la misma trama y reinventar/explorar ese
  espacio imaginario que se genera al leerlos en lugares que
  se leen distinto de las veces anteriores, pero se tratan
  de la misma trama... el mismo cuento.
Con este rollo quiero decir, que por usarse el lenguaje hablado,
  no se pierde este tipo de oportunidades de reencontrarse con
  el pasado cuando uno esta aprendiendo, incluso, creo que
  con reuniones periódicas, se alienta mas a rehacer "el cuento"
  en grupo, dándole además cuerpo a una organización (Smalltalking)
  que nos contiene/identifica y no nos deja solos frente a la pantalla
  (que no llega a ser siquiera un espejo).

>Asi, que para cuando un libro, Alejandro?

No creo que escriba un libro, seguramente lo harán otros.

>(Otro si: creo mas eficiente, en terminos de alcance, el expresar la
>idea, que simplemente invitar a la vivencia de la idea.... la forma
>zen de difusion sera interesante y fuerte, pero creo que muestra sus
>limitaciones)

No todos somos serviles a las ideas...
(podríamos hablar mas de esto, que creo, es el punto
  en el que más divergemos... si tenes ganas...)

>Noten por ejemplo a Martin Fowler: www.martinfowler.com. El podria
>haberse desaganitado haciendo presentaciones y reuniones, y nunca
>hubiera llegado a difundir sus ideas de la forma en la que llego si
>no fuera por el libro con sus colaboradores, y su magnifico web
>site. Lo mismo con Eric Evans.

"sus ideas" ? :-)
Las ideas que están en el libro ya no son suyas, sino del libro.
No podemos disfrutar un conjunto de palabras escritas,
  solo las ideas que juegan en nuestra cabeza.
Ese juego es el que tiene gusto a disfrute.
El diálogo con uno mismo, masticando las ideas,
  reconforta, pero no lo disfruto tanto como cuando
  lo abro hacia otro mientras lo miro a la cara.

>A Aristóteles lo salvo alguien que paso en limpio lo que decia... :-)

A que te referís con "lo salvo" ?
Quizás te referís a que alguien "salvo" sus ideas...
  apreciación que no comparto, pues creo que las ideas
  no necesitan de estar instanciadas, ni representadas en un soporte.

Para despedirme... un poquito de Smalltalk...

^1 abrazo
Ale.


----- Original Message -----
From: "ajlopez2000" <ajlopez@...>
To: <smalltalking@...>
Sent: Sunday, January 07, 2007 8:30 AM
Subject: [SPAM] Re: [objetos] Reunión y muestra en Enero de 2007


Hola gente!

Gracias Alejandro, por los enlaces, ya habia pasado por algunos, no
por otros. Conozco de tu predica desde hace anios, y es monumental
trabajo que has llevado a cabo, aunque disiento en algunos puntos
que no veo tan importantes en la creacion de software.

Igualmente insistiria en algo que hasta ahora insinue: habria que
poner varias de esas presentaciones, en un lenguaje de texto, tal
vez acompaniados de graficos, es la forma (me parece, una opinion),
para difundir mas la idea, explicarla, para los que no puedan ir a
una reunion.

Particularmente a mi, me gusta mucho la discusion por email, porque
permite eso: bajar a texto la idea. La imagen acompania, la
experiencia tambien, pero creo que todo eso se puede acompaniar de
explicacion de texto. Pero en algun momento, podria bajarse todo eso
a texto ordenado. El email tambien tiene limitaciones: termina
siendo un dialogo desordenado, donde tal vez los unicos que avanzan
son los dos o tres que activamente participan (siempre y cuando se
hayan puesto de acuerdo en los terminos, y crean que estan hablando
de lo mismo, sino pasa la gran pregunta Elvio "estamos hablando de
lo mismo?"), donde hay que buscar aca y alla un trozo de informacion
que falta en un mensaje.

La reunion fisica tiene sus limitaciones: no todos pueden ir, no
todo se entiende "enseguida", no todo se retiene, no hay
espacio/tiempo para discutir o pensar y rebatir o digerir.... Yo si
fuera a una reunion con David Hume, o Noam Chomsky, o Stephen Jay
Gould, apenas captaria algo de lo que quisieron decir, por ejemplo.

De ahi mi pregunta inicial: de las presentaciones que encontre
tuyas, no queda claro las definiciones, sentidos de algunas frases,
en particula mi pregunta era por las limiticiones de OO... Lo podria
extender a otras frases... Muchos hilos de esta lista tambien hacen
notar esa particularidad.

Asi, que para cuando un libro, Alejandro?

(Otro si: creo mas eficiente, en terminos de alcance, el expresar la
idea, que simplemente invitar a la vivencia de la idea.... la forma
zen de difusion sera interesante y fuerte, pero creo que muestra sus
limitaciones)

Noten por ejemplo a Martin Fowler: www.martinfowler.com. El podria
haberse desaganitado haciendo presentaciones y reuniones, y nunca
hubiera llegado a difundir sus ideas de la forma en la que llego si
no fuera por el libro con sus colaboradores, y su magnifico web
site. Lo mismo con Eric Evans.

A Aristoteles lo salvo alguien que paso en limpio lo que decia... :-)

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://www.ajlopez.net

--- En smalltalking@..., "Alejandro F. Reimondo"
<aleReimondo@...> escribió:
>
> Angel,
>
> En todas las presentaciones de la Tecnología de Objetos
>  partimos de reconocer los limites que impone la OO
>  y hacemos unos (breves) comentarios (solo un tímido
>  avance) sobre que es un ambiente, y cómo es utilizado
>  para superar esos límites.
> La base de la presentación que damos es la misma desde
>  hace aprox. 5 años (o más?) y en todo este tiempo no
>  he visto respuesta (ni aliento) en la audiencia que
>  promueva a profundizar mas allá de las bases.
>
> Cuando digo "la audiencia" me refiero no solo a profesionales
>  de informática en general, sino también a un distinguido
>  número de profesionales que se identifican como
>  Smalltalkers y no distinguen aún entre "image"(el
>  contenido) y ambiente;
> denominando a Smalltalk como :
>     1.- un LOO + un potente IDE
>     2.- un lenguaje dinámico
>     3.- un medio dinámico / un lugar dónde hay cosas
> Estas "definiciones" determinan un grado de entendimiento de
>  que es Smalltalk basado en su historia (en lo que fue definido
>  por los pioneros,..., en el pasado) y aunque son definiciones
>  útiles, aún hoy, en la enseñanza, no permite ver mas allá
>  de formulaciones de hace 30 años.
>
> En las reuniones hablamos mas en detalle y en un formato
>  de discusión creativa.
>
> El resultado de los esfuerzos de difusión y de esas
>  discusiones técnicas que hacemos en Smalltalking
>  es, a mi entender, muy pobre y frecuentemente encuentro
>  gente que ha participado de Smalltalking por años y
>  no entiende aún de que se está hablando como para
>  poderlo enunciar, defenderlo o criticar claramente.
> Esto es una constante, no solo en nuestro ámbito (la
>  informática), sino en casi todos los contextos de trabajo
>  que reconocen un ambiente. En las (siempre pocas)
>  oportunidades que he tenido de hablar con profesionales
>  de otras áreas de la problemática de ambiente he encontrado
>  mejor respuesta e incluso aportes muy valiosos.
> A veces me causa gracia (impotencia) el reconocer que
>  pese a identificar la problemática de ambiente
>  como un área de la informática, casi ningún profesional
>  dedicado a la informática se ocupa del tema.
>
> Enunciar los limites es algo aburrido para mi a esta altura
>  pero no estoy tan cansado como para hablar de esos puntos
>  en una reunión, dónde encuentro que me es de mas utilidad
>  que escribir sobre el tema.
>
> En pocas palabras, los limites vienen dados por el aplicar
>  el método único (reductivo) es decir, al encapsular y abstraer.
> Hay bastante literatura al respecto en casi todos los ámbitos
>  dónde se trata la problemática de ambiente.
>
> Te paso algunos links en Smalltalking:
>
> Presentaciones de TO...
>   http://www.smalltalking.net/Events/2003/Julio/Ahora%20Con%
20Objetos.ppt
>   http://www.smalltalking.net/Events/2002/Noviembre/msDotNet.htm
> Los documentos en la sección "Informática, Sistemas Abiertos y
pProblemática
> de Ambiente" en nuestra página de artículos:
> http://www.smalltalking.net/Papers/index.htm
>
> y en la red (para tomar "con pinzas")
> http://en.wikipedia.org/wiki/Reductionism
> http://en.wikipedia.org/wiki/Systems_Theory
>
> (algo relacionado) sistemas y cartesianismo
> http://pespmc1.vub.ac.be/MSTT.html
> http://ase.tufts.edu/cogstud/papers/time&obs.htm
>
> No dejes de acercarte a alguna reunión si podes
>  y te interesa el tema.
>
> hasta pronto,
> Ale.
>
>
>
> ----- Original Message -----
> From: "ajlopez2000" <ajlopez@...>
> To: <smalltalking@...>
> Sent: Friday, January 05, 2007 10:39 AM
> Subject: [SPAM] Re: [objetos] Reunión y muestra en Enero de 2007
>
>
> Hola gente!
>
> Alejandro, una pregunta: podrias enumerar los que son, desde tu
> punto de vista, "las limitaciones de la orientacion a objetos".
>
> Creo que gran parte de la definicion de "orientacion a objetos"
esta
> en tu articulo
>
> http://www.smalltalking.net/Papers/why/PorqueObjetos.htm
>
> Y de alguna forma, a lo largo del articulo, aparecen lo que
> consideras limitaciones.
>
> Pero no vendria mal para esta discusion, una enumeracion concreta
de
> las limitaciones. Supongo que ya lo trataron profusamente en la
> lista, pero no encuentro exactamente donde, o lo encuentro
> desperdigado de un lado a otro...
>
> Nos leemos!
>
> Angel "Java" Lopez
> http://www.ajlopez.com/
>
> --- En smalltalking@..., "Alejandro F. Reimondo"
> <aleReimondo@> escribió:
> >
> > Hola Angel,
> > Pienso casi lo mismo con respecto a todos los puntos,
> >  y comparto que se puede realizar actividades creativas
> >  en grupo sin usar un ambiente de objetos.
> > El usar un ambiente, no es contrario a no usarlo, sino
> >  complementario; la posibilidad de usarlo no esta dada
> >  por el aprender a usar una herramienta o un lenguaje,
> >  sino que esta dada por la gente que uno tiene a su lado
> >  y las posibilidades reales de usarlo (tener un proyecto
> >  en que aplicar esa energía). Por ser complementario
> >  es algo que suma y que no es "bueno para todos",
> >  ni es "el camino"...
> > Que otros caminos hay para abordar los limites
> >  de la orientación a objetos?
> > Que propuestas hay que no sea seguir haciendo
> >  lo mismo? (creando mas objetos y/o lenguajes)
> > hasta pronto,
> > Ale.
> >
> >
> >
>
>
>
> Para más información sobre la Asociación escribir a info@...
>
> Smalltalking es un espacio colaborativo creado para el estudio y
desarrollo
> en Ambientes de Objetos.
> Se sustenta gracias a la participación de sus socios.
>
> Las reglas de etiqueta sobre la lista están en
> http://www.smalltalking.net/join/netiquete.htm
>
> Enlaces a Yahoo! Grupos
>




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

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

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

Enlaces a Yahoo! Grupos

Hola gente!

Gracias Alejandro, por los enlaces, ya habia pasado por algunos, no
por otros. Conozco de tu predica desde hace anios, y es monumental
trabajo que has llevado a cabo, aunque disiento en algunos puntos
que no veo tan importantes en la creacion de software.

Igualmente insistiria en algo que hasta ahora insinue: habria que
poner varias de esas presentaciones, en un lenguaje de texto, tal
vez acompaniados de graficos, es la forma (me parece, una opinion),
para difundir mas la idea, explicarla, para los que no puedan ir a
una reunion.

Particularmente a mi, me gusta mucho la discusion por email, porque
permite eso: bajar a texto la idea. La imagen acompania, la
experiencia tambien, pero creo que todo eso se puede acompaniar de
explicacion de texto. Pero en algun momento, podria bajarse todo eso
a texto ordenado. El email tambien tiene limitaciones: termina
siendo un dialogo desordenado, donde tal vez los unicos que avanzan
son los dos o tres que activamente participan (siempre y cuando se
hayan puesto de acuerdo en los terminos, y crean que estan hablando
de lo mismo, sino pasa la gran pregunta Elvio "estamos hablando de
lo mismo?"), donde hay que buscar aca y alla un trozo de informacion
que falta en un mensaje.

La reunion fisica tiene sus limitaciones: no todos pueden ir, no
todo se entiende "enseguida", no todo se retiene, no hay
espacio/tiempo para discutir o pensar y rebatir o digerir.... Yo si
fuera a una reunion con David Hume, o Noam Chomsky, o Stephen Jay
Gould, apenas captaria algo de lo que quisieron decir, por ejemplo.

De ahi mi pregunta inicial: de las presentaciones que encontre
tuyas, no queda claro las definiciones, sentidos de algunas frases,
en particula mi pregunta era por las limiticiones de OO... Lo podria
extender a otras frases... Muchos hilos de esta lista tambien hacen
notar esa particularidad.

Asi, que para cuando un libro, Alejandro?

(Otro si: creo mas eficiente, en terminos de alcance, el expresar la
idea, que simplemente invitar a la vivencia de la idea.... la forma
zen de difusion sera interesante y fuerte, pero creo que muestra sus
limitaciones)

Noten por ejemplo a Martin Fowler: www.martinfowler.com. El podria
haberse desaganitado haciendo presentaciones y reuniones, y nunca
hubiera llegado a difundir sus ideas de la forma en la que llego si
no fuera por el libro con sus colaboradores, y su magnifico web
site. Lo mismo con Eric Evans.

A Aristoteles lo salvo alguien que paso en limpio lo que decia... :-)

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://www.ajlopez.net

--- En smalltalking@..., "Alejandro F. Reimondo"
<aleReimondo@...> escribió:
>
> Angel,
>
> En todas las presentaciones de la Tecnología de Objetos
>  partimos de reconocer los limites que impone la OO
>  y hacemos unos (breves) comentarios (solo un tímido
>  avance) sobre que es un ambiente, y cómo es utilizado
>  para superar esos límites.
> La base de la presentación que damos es la misma desde
>  hace aprox. 5 años (o más?) y en todo este tiempo no
>  he visto respuesta (ni aliento) en la audiencia que
>  promueva a profundizar mas allá de las bases.
>
> Cuando digo "la audiencia" me refiero no solo a profesionales
>  de informática en general, sino también a un distinguido
>  número de profesionales que se identifican como
>  Smalltalkers y no distinguen aún entre "image"(el
>  contenido) y ambiente;
> denominando a Smalltalk como :
>     1.- un LOO + un potente IDE
>     2.- un lenguaje dinámico
>     3.- un medio dinámico / un lugar dónde hay cosas
> Estas "definiciones" determinan un grado de entendimiento de
>  que es Smalltalk basado en su historia (en lo que fue definido
>  por los pioneros,..., en el pasado) y aunque son definiciones
>  útiles, aún hoy, en la enseñanza, no permite ver mas allá
>  de formulaciones de hace 30 años.
>
> En las reuniones hablamos mas en detalle y en un formato
>  de discusión creativa.
>
> El resultado de los esfuerzos de difusión y de esas
>  discusiones técnicas que hacemos en Smalltalking
>  es, a mi entender, muy pobre y frecuentemente encuentro
>  gente que ha participado de Smalltalking por años y
>  no entiende aún de que se está hablando como para
>  poderlo enunciar, defenderlo o criticar claramente.
> Esto es una constante, no solo en nuestro ámbito (la
>  informática), sino en casi todos los contextos de trabajo
>  que reconocen un ambiente. En las (siempre pocas)
>  oportunidades que he tenido de hablar con profesionales
>  de otras áreas de la problemática de ambiente he encontrado
>  mejor respuesta e incluso aportes muy valiosos.
> A veces me causa gracia (impotencia) el reconocer que
>  pese a identificar la problemática de ambiente
>  como un área de la informática, casi ningún profesional
>  dedicado a la informática se ocupa del tema.
>
> Enunciar los limites es algo aburrido para mi a esta altura
>  pero no estoy tan cansado como para hablar de esos puntos
>  en una reunión, dónde encuentro que me es de mas utilidad
>  que escribir sobre el tema.
>
> En pocas palabras, los limites vienen dados por el aplicar
>  el método único (reductivo) es decir, al encapsular y abstraer.
> Hay bastante literatura al respecto en casi todos los ámbitos
>  dónde se trata la problemática de ambiente.
>
> Te paso algunos links en Smalltalking:
>
> Presentaciones de TO...
>   http://www.smalltalking.net/Events/2003/Julio/Ahora%20Con%
20Objetos.ppt
>   http://www.smalltalking.net/Events/2002/Noviembre/msDotNet.htm
> Los documentos en la sección "Informática, Sistemas Abiertos y
pProblemática
> de Ambiente" en nuestra página de artículos:
> http://www.smalltalking.net/Papers/index.htm
>
> y en la red (para tomar "con pinzas")
> http://en.wikipedia.org/wiki/Reductionism
> http://en.wikipedia.org/wiki/Systems_Theory
>
> (algo relacionado) sistemas y cartesianismo
> http://pespmc1.vub.ac.be/MSTT.html
> http://ase.tufts.edu/cogstud/papers/time&obs.htm
>
> No dejes de acercarte a alguna reunión si podes
>  y te interesa el tema.
>
> hasta pronto,
> Ale.
>
>
>
> ----- Original Message -----
> From: "ajlopez2000" <ajlopez@...>
> To: <smalltalking@...>
> Sent: Friday, January 05, 2007 10:39 AM
> Subject: [SPAM] Re: [objetos] Reunión y muestra en Enero de 2007
>
>
> Hola gente!
>
> Alejandro, una pregunta: podrias enumerar los que son, desde tu
> punto de vista, "las limitaciones de la orientacion a objetos".
>
> Creo que gran parte de la definicion de "orientacion a objetos"
esta
> en tu articulo
>
> http://www.smalltalking.net/Papers/why/PorqueObjetos.htm
>
> Y de alguna forma, a lo largo del articulo, aparecen lo que
> consideras limitaciones.
>
> Pero no vendria mal para esta discusion, una enumeracion concreta
de
> las limitaciones. Supongo que ya lo trataron profusamente en la
> lista, pero no encuentro exactamente donde, o lo encuentro
> desperdigado de un lado a otro...
>
> Nos leemos!
>
> Angel "Java" Lopez
> http://www.ajlopez.com/
>
> --- En smalltalking@..., "Alejandro F. Reimondo"
> <aleReimondo@> escribió:
> >
> > Hola Angel,
> > Pienso casi lo mismo con respecto a todos los puntos,
> >  y comparto que se puede realizar actividades creativas
> >  en grupo sin usar un ambiente de objetos.
> > El usar un ambiente, no es contrario a no usarlo, sino
> >  complementario; la posibilidad de usarlo no esta dada
> >  por el aprender a usar una herramienta o un lenguaje,
> >  sino que esta dada por la gente que uno tiene a su lado
> >  y las posibilidades reales de usarlo (tener un proyecto
> >  en que aplicar esa energía). Por ser complementario
> >  es algo que suma y que no es "bueno para todos",
> >  ni es "el camino"...
> > Que otros caminos hay para abordar los limites
> >  de la orientación a objetos?
> > Que propuestas hay que no sea seguir haciendo
> >  lo mismo? (creando mas objetos y/o lenguajes)
> > hasta pronto,
> > Ale.
> >
> >
> >
>
>
>
> Para más información sobre la Asociación escribir a info@...
>
> Smalltalking es un espacio colaborativo creado para el estudio y
desarrollo
> en Ambientes de Objetos.
> Se sustenta gracias a la participación de sus socios.
>
> Las reglas de etiqueta sobre la lista están en
> http://www.smalltalking.net/join/netiquete.htm
>
> Enlaces a Yahoo! Grupos
>

Angel,

En todas las presentaciones de la Tecnología de Objetos
  partimos de reconocer los limites que impone la OO
  y hacemos unos (breves) comentarios (solo un tímido
  avance) sobre que es un ambiente, y cómo es utilizado
  para superar esos límites.
La base de la presentación que damos es la misma desde
  hace aprox. 5 años (o más?) y en todo este tiempo no
  he visto respuesta (ni aliento) en la audiencia que
  promueva a profundizar mas allá de las bases.

Cuando digo "la audiencia" me refiero no solo a profesionales
  de informática en general, sino también a un distinguido
  número de profesionales que se identifican como
  Smalltalkers y no distinguen aún entre "image"(el
  contenido) y ambiente;
denominando a Smalltalk como :
     1.- un LOO + un potente IDE
     2.- un lenguaje dinámico
     3.- un medio dinámico / un lugar dónde hay cosas
Estas "definiciones" determinan un grado de entendimiento de
  que es Smalltalk basado en su historia (en lo que fue definido
  por los pioneros,..., en el pasado) y aunque son definiciones
  útiles, aún hoy, en la enseñanza, no permite ver mas allá
  de formulaciones de hace 30 años.

En las reuniones hablamos mas en detalle y en un formato
  de discusión creativa.

El resultado de los esfuerzos de difusión y de esas
  discusiones técnicas que hacemos en Smalltalking
  es, a mi entender, muy pobre y frecuentemente encuentro
  gente que ha participado de Smalltalking por años y
  no entiende aún de que se está hablando como para
  poderlo enunciar, defenderlo o criticar claramente.
Esto es una constante, no solo en nuestro ámbito (la
  informática), sino en casi todos los contextos de trabajo
  que reconocen un ambiente. En las (siempre pocas)
  oportunidades que he tenido de hablar con profesionales
  de otras áreas de la problemática de ambiente he encontrado
  mejor respuesta e incluso aportes muy valiosos.
A veces me causa gracia (impotencia) el reconocer que
  pese a identificar la problemática de ambiente
  como un área de la informática, casi ningún profesional
  dedicado a la informática se ocupa del tema.

Enunciar los limites es algo aburrido para mi a esta altura
  pero no estoy tan cansado como para hablar de esos puntos
  en una reunión, dónde encuentro que me es de mas utilidad
  que escribir sobre el tema.

En pocas palabras, los limites vienen dados por el aplicar
  el método único (reductivo) es decir, al encapsular y abstraer.
Hay bastante literatura al respecto en casi todos los ámbitos
  dónde se trata la problemática de ambiente.

Te paso algunos links en Smalltalking:

Presentaciones de TO...
   http://www.smalltalking.net/Events/2003/Julio/Ahora%20Con%20Objetos.ppt
   http://www.smalltalking.net/Events/2002/Noviembre/msDotNet.htm
Los documentos en la sección "Informática, Sistemas Abiertos y pProblemática
de Ambiente" en nuestra página de artículos:
http://www.smalltalking.net/Papers/index.htm

y en la red (para tomar "con pinzas")
http://en.wikipedia.org/wiki/Reductionism
http://en.wikipedia.org/wiki/Systems_Theory

(algo relacionado) sistemas y cartesianismo
http://pespmc1.vub.ac.be/MSTT.html
http://ase.tufts.edu/cogstud/papers/time&obs.htm

No dejes de acercarte a alguna reunión si podes
  y te interesa el tema.

hasta pronto,
Ale.



----- Original Message -----
From: "ajlopez2000" <ajlopez@...>
To: <smalltalking@...>
Sent: Friday, January 05, 2007 10:39 AM
Subject: [SPAM] Re: [objetos] Reunión y muestra en Enero de 2007


Hola gente!

Alejandro, una pregunta: podrias enumerar los que son, desde tu
punto de vista, "las limitaciones de la orientacion a objetos".

Creo que gran parte de la definicion de "orientacion a objetos" esta
en tu articulo

http://www.smalltalking.net/Papers/why/PorqueObjetos.htm

Y de alguna forma, a lo largo del articulo, aparecen lo que
consideras limitaciones.

Pero no vendria mal para esta discusion, una enumeracion concreta de
las limitaciones. Supongo que ya lo trataron profusamente en la
lista, pero no encuentro exactamente donde, o lo encuentro
desperdigado de un lado a otro...

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/

--- En smalltalking@..., "Alejandro F. Reimondo"
<aleReimondo@...> escribió:
>
> Hola Angel,
> Pienso casi lo mismo con respecto a todos los puntos,
>  y comparto que se puede realizar actividades creativas
>  en grupo sin usar un ambiente de objetos.
> El usar un ambiente, no es contrario a no usarlo, sino
>  complementario; la posibilidad de usarlo no esta dada
>  por el aprender a usar una herramienta o un lenguaje,
>  sino que esta dada por la gente que uno tiene a su lado
>  y las posibilidades reales de usarlo (tener un proyecto
>  en que aplicar esa energía). Por ser complementario
>  es algo que suma y que no es "bueno para todos",
>  ni es "el camino"...
> Que otros caminos hay para abordar los limites
>  de la orientación a objetos?
> Que propuestas hay que no sea seguir haciendo
>  lo mismo? (creando mas objetos y/o lenguajes)
> hasta pronto,
> Ale.
>
>
>



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

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

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

Enlaces a Yahoo! Grupos

Hola Angel,

>Y la tecnología es accesoria.
...
>Y cuando una persona del grupo se
> dedica a algo, todos saben por que
>y para que. La comunicación es importante.
...
>Y todo sin ambiente... :-) (perdón, perdón,
> no pude contenerme... :-) :-)

jajaja!
También lo podrías hacer con un
  ambiente, si trabajaras con uno.

El usar un ambiente no se contrapone a ninguna
  metodología ni técnica (nueva o antigua);
  no es contrario, es complementario.
Y como todo complemento, no es indispensable
  para hacer software de la misma forma que lo hace
  mi vecino (*).

hasta pronto,
Ale.

(*) con "mi vecino" quiero decir, hacer lo mismo
  que hacen todos, pues si son muchos parecería
  que uno no puede ambicionar hacer algo distinto...
  y para eso no se necesita mas que escribir
  el "código correcto".


----- Original Message -----
From: "ajlopez2000" <ajlopez@...>
To: <smalltalking@...>
Sent: Saturday, January 06, 2007 7:42 AM
Subject: [SPAM] RE: [SPAM] Re: [objetos] Reunión y muestra en Enero de 2007


Hola gente!

Si, Elvio, algo entiendo de tu postura, la encuentro en otras
personas tambien... Igualmente trataria de exponer esto, con
respecto a este ultimo mensaje tuyo.

Mis envios de hace un tiempo sobre enlaces y recursos de
metodologias agiles, te van a mostrar que justamente en ese tipo de
metodologias (por llamarlas de alguna forma), no pasa para nada eso
que comentas de "desprecio" del lider.

Y vas a encontrar mucho de informacion sobre desarrollo de la
persona. En el manifiesto agil, lo importante son las personas (no
solo en su desarrollo, en varios aspectos).

Y la tecnologia es accesoria.

Y no se acortan o manipulan los tiempos a cualquier precio (ejemplo
practicamente maximo de eso es Scrum).

Y no se mutila al ser humano.

Y el poder, de alguna forma es compartido (varia creo de
metodologia, pero pueden ver Scrum como ejemplo).

Y cuando una persona del grupo se dedica a algo, todos saben por que
y para que. La comunicacion es importante.

Y todo sin ambiente... :-) (perdon, perdon, no pude contenerme... :-
) :-)

Nos leemos!

Angel "Java" Lopez (bueno, hoy viene firma larga... :-)
http://www.ajlopez.com
http://www.ajlopez.net
http://ajlopez.zoomblog.com
http://ajlopez.wordpress.com
http://www.msmvps.com/lopez

--- En smalltalking@..., "Elvio Fernandez"
<elvio.fernandez@...> escribió:
>
> Hola Angel, lista
>
> Yo entiendo lo que vos decis (no quiere decir que este totalmente
de
> acuerdo) y supongo que vos comprendes algo de lo mio tambien.
> Se me complica un poco salir de mi optica de programador. Lo que
siempre me
> paso fue que percibi (quizas es algo muy subjetivo) que existe una
brecha
> entre el tipo que pone los ladrillos y el tipo que dirige la
construccion
> del edificio. El que pone los ladrillos comprende el
funcionamiento finito
> (detallado) del sistema en construccion. Ese conocimiento le da
otra
> perspectiva y esto ultimo siempre es despreciado (en algun
sentido) por el
> lider.
> La soledad del poder (jejej) muchas veces lo envuelve en una
burbuja
> "idealista" en otro sentido.
> He leido poca literatura con respecto a estos temas. Pero lo que
noto es que
> se centran en el aceitado de los mecanismos utilizados para
acortar los
> tiempos de desarrollo y la concrecion del proyecto. Como se lleva
a cabo
> estos dos utlimos puntos en la realidad? Simple: a cualquier
costo. Y al
> final de cuentas el costo es humano... se entiende? El acortar los
plazos de
> analisis e implementacion tiene consecuencias, esas consecuencias
son
> desestimadas y al ser asi, siempre hay poco lugar para el
replanteo y un
> analisis mas profundo. Yo entiendo, hay que llegar a un equilibrio
pero ese
> equilibrio nunca esta.
> A lo largo de todo el proceso de desarrollo lo que se desestima es
el
> individuo. Es la mutilacion de la parte humana de un proceso (el
desarrollo)
> escencialmente humano.
>
>
> " No creo que Smalltalk no sea funcional al mercado, o que no sea
> exitoso. Creo que hay mucho Smalltalk dando vueltas por ahi, de ahi
> que tampoco crea que sea "marginal" (adjetivo que aparecio en una
> pregunta de Alejandro, que recuerde). Pero insisto: hay pila de
> software creado sin ambiente, exitoso."
>
> En mi opinion lo que es "marginal" es la utilizacion del Smalltalk
en todo
> su potencial. Lo mas tipico de hoy es que se lo utilice como
un "lenguaje"
> de scripting ja!
> Otra cosa marginal es el ejercicio de repensar y critica. Algo
promovido por
> Smalltalk donde el protagonista es el individuo que desarrolla, su
busqueda
> y su experimentacion. Y justamente eso no es funcional al mercado.
El
> mercado necesita otro tipo de mano de obra. Soy nuevito en la
lista pero
> creo que de esto se ha hablado bastante no?
>
> Saludos
> Elvio
>




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

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

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

Enlaces a Yahoo! Grupos