Muchos aFloat

[GallegO]

Gente:

Quería saber si alguien se le ocurre de que forma uno puede evitar la
instanciación de Float en Dolphin, o si se les ocurren en cualquier
Smalltalk en forma transparente. Tengo un problemita con algunos
millones de floats. En algunos lados lo puedo solucionar con un
lightweight pero cuando se usan primitivas en un calculo estoy al
horno.

Gracias por su ayuda :)

Saludos
GallegO

[dcoro...@gmail.com]

Hola GallegO,
Supongo que habrás hecho un flyweight y es lo que generalmente me
sirvió. Tal vez si contarás un poco mas surjan mas ideas, en las cosas
que me topé terminé por darme cuenta que los números son muchísimos
menos que los que parecen, en matemática son infinitos pero en la
compu no, y en la realidad mucho menos.

Abrazo

Diego

[Angel Java Lopez]

Interesante tema/problema..

Por que hay millones de float? Yo me imagino algun calculo, pero igual luego el garbage collector deberia liberarlos. El problema es la memoria? se acaba? Se necesitan los millones de floats, digo, que esten referenciados y no sean liberados por el GC? no habra forma de cambiar el algoritmo? O el problema es el tiempo (mucho tiempo creando) y no la memoria?

2012/5/3 dcoro...@gmail.com <dcoro...@gmail.com>

--
To post to this group, send email to clubSm...@googlegroups.com
To unsubscribe from this group, send email to clubSmalltal...@googlegroups.com

http://www.clubSmalltalk.org

[Juan Vuletich (mail lists)]

FloatArray (como en Squeak y sus derivados)? No es transparente, por
supuesto. Podés contar algo más?

> --
> To post to this group, send email to clubSm...@googlegroups.com
> To unsubscribe from this group, send email to
> clubSmalltal...@googlegroups.com
>
> http://www.clubSmalltalk.org
>

Cheers,
Juan Vuletich

[GallegO]

Hola:

Les respondo aclarando la situación.

Ya implemente un flyweight para cuando traigo floats de la base de
datos. Luego de observar los resultados llegue a la conclusión que por
perfomance, en mi caso particular, no valía la pena el flyweight (que
lo habia implementado con un WeakSet). La mayoría de mis valores eran
0.0, entonces simplemente evito el 0.0, cuando viene un 0.0
instanciado por el driver, en el lugar donde se mapea eso a los
objetos directamente si viene 0.0 lo descarto y al objeto le pongo el
SmallInteger 0, simple y rápido. Si se pone peludo algun día tenes la
posibilidad de hacer eso e incluso hacerlo para Date, Time, TimeStamp
e incluso String.

Pero el problema que tengo es en unos objetos que calculamos en
memoria para un periodo x de tiempo. Por ejemplo calcular la
producción de 30 dias de 5000 pozos, suponiendo que cada producción
tiene 20 valores numericos que mantiene en variables de instancia, eso
te da unos 3 millones de instancias de Float.

Ahora, entiendo perfectamente que podemos trabajar ahí también para
evitar tener todo eso calculado, o evitar tener al menos tantos Float
0.0 pero por como están programados todos los cálculos se hace muy
complicado (y feo) manejar esto en todos lados. De ultima que cada
seter de las variables de instancias pongo codigo que maneje un
flyweight o el Float zero al menos, pero es algo feo feo.

Por eso pregunto por algo "transparente" como seria poder modificar la
VM o las primitivas al menos, que en mi caso por ser Dolphin no puedo.

Recién veo el mail de Juan Vuletich, en Dolphin tengo FloatArray
tambien. Calculo que en vez de variables de instancia podría tener un
array de estos en mis objetos y los accessors que apunten a cada una
de las posiciones del array. No se si te referis a que es posible ese
uso. Ja! no me imagino lo que tendría que testear...

De todas maneras tener en Smalltalk reflexividad sobre la
instanciacion como los Symbol estaría buenísimo.

Bueno, viendo esta perspectiva ¿que me sugieren? :D

Saludos
GallegO

El día 3 de mayo de 2012 14:16, Angel Java Lopez
<ajlop...@gmail.com> escribió:

[dcoro...@gmail.com]

Tal vez me estoy yendo de tema, pero en un sistema que hice para
procesar muchos datos terminé aplicando flyweights a cosas que no
esperaba, como numeros, fechas o nombres. Por ejemplo, si tengo una
colección con 1 millon de "Facturas del mes", entonces la cantidad de
fechas posibles son 30 y no 1 millón. Y está claro que tener 30 fechas
es mas barato en términos de memoria y de muchas operaciones (y a
veces mas caro de instanciar al principio). Viniendo de un pasado de
bases de datos relacionales, siempre tendía a "factorizar" lo obvio,
cosas como Ciudad, Cliente, Género, Tipo, etc.. Pero nunca pensé que
el importe de una factura , la fecha o un "campo string" debían
factorizarse. Pero en Smalltalk resulta muy natural hacerlo y darse
cuenta que tampoco suelen existir 1 millón de importes distintos, ni
un millón de nombres distintos, de hecho los nombres de personas son
muy pocos. Además en ese tipo de colecciones, los objetos suelen tener
mas de una fecha y mas de un variable de instancia de tipos numéricos,
por lo que la misma instancia suele vivir en varias partes del objeto.
Si me tocara analizar a la población de Argentina, la fechas de
nacimiento REALES no serían 40 millones, serían unas 40 mil, o sea mil
veces menos objetos. Algo que a veces pasa es que cuando se encuentran
muchas repeticiones el tiempo de instanciación de las colecciones
también baja mucho porque a la VM le cuesta menos hacer búsquedas que
reservar tanta memoria.
Para tranformar un objeto en otro que esté siendo usado previamente
les mando el mensaje #used, que obviamente me devuelve el objeto del
pool para su reemplazo. Todo esto tiene muy bajo costo en términos de
diseño y empiezan a aparecer beneficios por donde uno menos lo espera.
En mi caso, a clave fue sacarme las reglas de factorización de la
cabeza y prestarle mas atención al inspector de Smalltalk.

Diego Coronel

On 3 mayo, 14:16, Angel Java Lopez <ajlopez2...@gmail.com> wrote:
> Interesante tema/problema..
>
> Por que hay millones de float? Yo me imagino algun calculo, pero igual
> luego el garbage collector deberia liberarlos. El problema es la memoria?
> se acaba? Se necesitan los millones de floats, digo, que esten
> referenciados y no sean liberados por el GC? no habra forma de cambiar el
> algoritmo? O el problema es el tiempo (mucho tiempo creando) y no la
> memoria?
>

> 2012/5/3 dcorone...@gmail.com <dcorone...@gmail.com>

[dcoro...@gmail.com]

Si el tema es "emprolijar" lo feo podrías subclasificar Float y hacer
algo similar a lo que Symbol hace con String. Podrías mantener un
pool, incluso con algún criterio estadístico, en donde no guardes todo
sino lo que mas te aparezca (como el 0.0). También podrías redondear
lo que se pueda, no nos olvidemos que Float ya trunca las cosas y se
manda sus mocos sin ayuda de nadie.

> <ajlopez2...@gmail.com> escribió:

>
>
>
> > Interesante tema/problema..
>
> > Por que hay millones de float? Yo me imagino algun calculo, pero igual luego
> > el garbage collector deberia liberarlos. El problema es la memoria? se
> > acaba? Se necesitan los millones de floats, digo, que esten referenciados y
> > no sean liberados por el GC? no habra forma de cambiar el algoritmo? O el
> > problema es el tiempo (mucho tiempo creando) y no la memoria?
>

> > 2012/5/3 dcorone...@gmail.com <dcorone...@gmail.com>

[GallegO]

Diego:

yo tengo las mismas estadísticas pero lo que no viene de la BD es más
complicado o queda más a la vista.
(5000 / 24.0) used o #unique o lo que sea, es un bajón. Cuando viene
de la BD te queda escondido en el mapeo que si es relativamente
automático no tenes que volverlo a tocar.

Subclasificar Float? no se haria una mescolanza terrible?

Para eso uso ScaledDecimal (despues vemos como anda :)
El tema es la performance también, por eso me gusta el Float.

Saludos


El día 3 de mayo de 2012 14:43, dcoro...@gmail.com
<dcoro...@gmail.com> escribió:

[Juan]

Hola Gallego ,gente

Che una idea no se si aplica,
No podrias usar un proxy cuando traes la data, y alli manejar el caso del 0.0 yo usaria un singleton, pero aqui
viene mi duda , no son los floats flyweight en Dolphin? sino es asi, podrias usar un factory o sea un metodo de creacion en la clase que devuelva una instancia siempre la misma, o que administre proxy's donde tambien podrias volver a administrar la creacion, o sea un mix entre flyweight y proxy.
que te/les parece?
salud2
jmdc

2012/5/3 dcoro...@gmail.com <dcoro...@gmail.com>

[dcoro...@gmail.com]

Tirando ideas sin conocer tu problema te diría
0) Me parece bien que si podés resolverlo en el mapeo, entonces no
usar mensajes #used ni subclasificar Float.
1) Que uses Set en lugar de WeakSet (y que te pongas las pilas en
manenter ese pool ;-))
2) Que no metas en el pool todos los Floats, solo los mas usados. Si
instancias 3 millones y te quedan 3 millones en el pool, entonces no
sirvió para nada. Probá bajando el tamaño del pool a 100, a 1000, a
10000 o a lo que te resulte óptimo. Hoy tenés un pool de 1 objeto, el
0.0 :-)
3) Trataría de no tener ningún prejuicio sobre qué será rápido o qué
será lento. Incluso si la resolución te da, podrías usar enteros.

Saludos,
Diego

On 3 mayo, 14:54, GallegO <fxgall...@gmail.com> wrote:
> Diego:
>
> yo tengo las mismas estadísticas pero lo que no viene de la BD es más
> complicado o queda más a la vista.
> (5000 / 24.0) used o #unique o lo que sea, es un bajón. Cuando viene
> de la BD te queda escondido en el mapeo que si es relativamente
> automático no tenes que volverlo a tocar.
>
> Subclasificar Float? no se haria una mescolanza terrible?
>
> Para eso uso ScaledDecimal (despues vemos como anda :)
> El tema es la performance también, por eso me gusta el Float.
>
> Saludos
>

> El día 3 de mayo de 2012 14:43, dcorone...@gmail.com
> <dcorone...@gmail.com> escribió:

[GallegO]

Hola Marcelo,

si es lo que veniamos planteando, no se si no se entendio pero
basicamente para cuando viene de las BD la cosa anda barbara, el tema
es que cuando haces cuentas, intervienen primitivas y la VM se encarga
de instanciar el resultado y no tenes control desde el lado de
Smalltalk de que numero se instancia (por lo menos en Dolphin no
conozco forma de controlarlo).

Y no obvio en Dolphin no son float flyweight ni mucho menos jaja pesan
como 80 megas los float esos jaja increible para tener todos 0 un
cagadon.

Saludos
GallegO

[Juan]

Galllego

pero se me ocurre algo re facil. quizas bobo, pero ahi va,
seguramente en algun momento instancias el float  o lo hace el mapper ?
si lo hace el mapper busca donde si lo haces vos , algo asi;


asFloat: aBuffer
"devuelve un float del abuffer value "
"suponiendo que buffer es lo que te da la db"
^ aBuffer value= 0.0
 ifTrue:[  self ceroFloat " devuelve una instancias de float 0.0"]
 ifFalse:[ "lo que hacia antes"].
Tambien se me ocurre el problema podria estar en el mapeador
que usan?
ReStore?
unop propio?
o el de Alan Knight no recuerdo el nombre...
saludos
jmdc

2012/5/3 GallegO <fxga...@gmail.com>

[GallegO]

Hola Marcelo :

no te llegan mis mails?
Si, digo que para lo que viene de la BD ya lo hago asi, y estoy muy contento :)


Saludos

[Juan]

gallego

Si me llegan tus email. de hecho contesto,
che entonces si lo haces asi no deberia haber mas que un solo 0.0.
digo el metodo que llame ceroFloat es una variable de clase en algun lado
lo guardas y en el ifTrue: lo devolves ,no podrias tener mas de uno con value 0.0
Por ahi .¿estoy comentiendo algun error, no se decime :)
salu2
jmdc.

2012/5/3 GallegO <fxga...@gmail.com>

[GallegO]

Marcelo:

Te copio un pedazo de algo que había puesto en otro mail:

"Pero el problema que tengo es en unos objetos que calculamos en
memoria para un periodo x de tiempo. Por ejemplo calcular la
producción de 30 dias de 5000 pozos, suponiendo que cada producción
tiene 20 valores numericos que mantiene en variables de instancia, eso
te da unos 3 millones de instancias de Float."

Es decir, el problema no es con lo que viene de la BD, eso lo manejo
de taquito, el tema es con lo que calculo en memoria, por ejemplo:

| oc |
oc := OrderedCollection new.
10000000 timesRepeat: [oc add: 1 * 0.0].

Saludos
Gallego

[Smalltalk]

GallegO,

Lo que hice hace un tiempo con el UML Almighty fue usar una LookupTable con
el Float printString como Key y el Float como value.
Si definis la presicion de X después del coma no hay problema. No se lo
podes aplicar a tu caso.
Seria algo asi:

cache: aFloat

^floatCache at: aFloat printString ifAbsent: [floatCache at: aFloat
printString put: aFloat. aFloat]

Se puede poner:
cache: aFloat presicion: anInteger
^floatCache at: (aFloat printString first: anInteger) ifAbsent:
[floatCache at: aFloat printString put: aFloat. aFloat]

Lo malo de este encare es si tenes los cálculos distribuidos, hay que
modificar mucho para integrarlo.

Es bastante sencillo pero me fue muy útil.

Saludos,
Bruno



-----Mensaje original-----
De: clubsm...@googlegroups.com [mailto:clubsm...@googlegroups.com]
En nombre de GallegO
Enviado el: Thursday, May 03, 2012 3:37 PM
Para: clubsm...@googlegroups.com
Asunto: Re: [clubSmalltalk] Re: Muchos aFloat

[Esteban A. Maringolo]

Igual creo que lo que el gallego plantea, es que los floats los instancia la VM (mediante alguna primitiva) no tenes chances de evitarlos.

Osea... si tenes 1000 operaciones que multiplican por un float, por más que la parte decimal de esos resultados sea cero, y por lo tanto un SmallInteger podría cubrir la necesidad de representación, la VM va a instanciar los 1000 floats.

Creo que dado el caso de dolphin, no podes parchear la VM ni el compiler.

Saludos.

Esteban A. Maringolo

[Juan Vuletich (mail lists)]

Quoting GallegO <fxga...@gmail.com>:

> Hola:
>
> ...

>
> Recién veo el mail de Juan Vuletich, en Dolphin tengo FloatArray
> tambien. Calculo que en vez de variables de instancia podría tener un
> array de estos en mis objetos y los accessors que apunten a cada una
> de las posiciones del array. No se si te referis a que es posible ese
> uso. Ja! no me imagino lo que tendría que testear...

> Saludos
> GallegO

Si, a eso me refiero. Incluso, si tenes las operaciones de FloatArray
necesarias, durante los calculos no necesitas alocar Floats. Hacés
directamente las cuentas con los FloatArray, y usando operaciones que
sobreescriben los valores (en vez de crear instancias nuevas).

Cheers,
Juan Vuletich

[GallegO]

Juan:

Esta buena la idea. Por ahora voy a tratar de atacar directamente el
código que genera el "problemita", siempre es lo mas simple, aunque
quede feo.

Mi idea era saber si alguien conocía algo mas transparente. Tenia un
1% de esperanza.

Ya que vos haces un Smalltalk, no estaría mal tener en cuenta alguna
estrategia para manejar eso. No se si eso esta totalmente fuera del
target de tu producto.

Saludos
GallegO

El día 3 de mayo de 2012 16:37, Juan Vuletich (mail lists)
<juan...@jvuletich.org> escribió:

[Juan Vuletich (mail lists)]

Hola GallegO,

Quoting GallegO <fxga...@gmail.com>:

> Juan:
>
> Esta buena la idea. Por ahora voy a tratar de atacar directamente el
> código que genera el "problemita", siempre es lo mas simple, aunque
> quede feo.
>
> Mi idea era saber si alguien conocía algo mas transparente. Tenia un
> 1% de esperanza.
>
> Ya que vos haces un Smalltalk, no estaría mal tener en cuenta alguna
> estrategia para manejar eso. No se si eso esta totalmente fuera del
> target de tu producto.
>
> Saludos
> GallegO

Yo no llamaría a Cuis "producto", ya que no se vende! Prefiero
llamarlo "proyecto".

Una estrategia para hacer algo como lo que vos imaginás podría llegar
a entrar a mi "radar" si tuviera un problema y esa fuera la mejor
solución. En este caso, la solución que yo usaría es la que ya te
sugerí; así que si estuviera en tu lugar (pero usando Cuis), igual
tampoco intentaría meter en la VM lo que vos decís...

Yo te diría que pienses un ratito en lo que sugiero. La mejora en
performance sería muy grande (hablo por experiencia).

> El día 3 de mayo de 2012 16:37, Juan Vuletich (mail lists)
> <juan...@jvuletich.org> escribió:
>> Quoting GallegO <fxga...@gmail.com>:
>>
>>> Hola:
>>>
>>> ...
>>>
>>>
>>> Recién veo el mail de Juan Vuletich, en Dolphin tengo FloatArray
>>> tambien. Calculo que en vez de variables de instancia podría tener un
>>> array de estos en mis objetos y los accessors que apunten a cada una
>>> de las posiciones del array. No se si te referis a que es posible ese
>>> uso. Ja! no me imagino lo que tendría que testear...
>>> Saludos
>>>  GallegO
>>
>>
>> Si, a eso me refiero. Incluso, si tenes las operaciones de FloatArray
>> necesarias, durante los calculos no necesitas alocar Floats. Hacés
>> directamente las cuentas con los FloatArray, y usando operaciones que
>> sobreescriben los valores (en vez de crear instancias nuevas).
>>
>> Cheers,
>> Juan Vuletich
>>
>>

Cheers,
Juan Vuletich

[Angel Java Lopez]

Hola gente!

Bien, fui entendiendo... Pero lo que no me quedo claro es:

- Cual es el problema de tener 3 millones de instancias de float?

Digo, en que se nota? 

1 - En performance? 

2 - O da en algun momento: falta memoria?

Si es el primer caso, es por el tiempo de creacion de los objetos? Como se midio que era por eso?

2012/5/3 GallegO <fxga...@gmail.com>

[GallegO]

Angel:

No es un tema de tiempo, mas que nada de memoria y limites en el
tamaños de la tabla de objetos en el ObjectMemory.

En Dolphin por defecto el limite es bastante bajo, 8 millones y pico
de objetos. Se puede agrandar patcheando el image pero a veces genera
cierta inestabilidad (Me a pasado en win7 64 mas que nada no se que
tendra que ver).

Digamos que hago el calculo un par de veces y como todo es un objeto,
suma todo el ambiente, metodos, strings, etc y llegas muy rápido al
limite si es que te zarpas.

En Squeak con Cog inclusive la vm viene limitada a 512 mb así que si
te pasas de eso te sale un lindo cartelito. Se llega bastante fácil a
eso.

Creo que VW debe ser el mas preparadito, hasta donde recuerdo la
configuración de memoria era una Strategy o algo asi. No se cuales son
los limites reales, quizás Andres nos pueda contar.

Bueno, por ultimo decir que es obvio como decía Diego que no nos hace
falta tener todos estos objetos pero que a veces surgen estos
problemas y en algunos casos no se pueden atacar en forma tan
transparente, y eso jode.

Saludos
Gallego

El día 3 de mayo de 2012 17:04, Angel Java Lopez

[GallegO]

> Yo no llamaría a Cuis "producto", ya que no se vende! Prefiero llamarlo
> "proyecto".

Ok :)

> Una estrategia para hacer algo como lo que vos imaginás podría llegar a
> entrar a mi "radar" si tuviera un problema y esa fuera la mejor solución. En
> este caso, la solución que yo usaría es la que ya te sugerí; así que si
> estuviera en tu lugar (pero usando Cuis), igual tampoco intentaría meter en
> la VM lo que vos decís...

> Yo te diría que pienses un ratito en lo que sugiero. La mejora en
> performance sería muy grande (hablo por experiencia).

Ok. Conoces alguna implementacion de la aritmética en estos External Float?

Saludos
GallegO

>
>
>> El día 3 de mayo de 2012 16:37, Juan Vuletich (mail lists)
>> <juan...@jvuletich.org> escribió:
>>>
>>> Quoting GallegO <fxga...@gmail.com>:
>>>
>>>> Hola:
>>>>
>>>> ...
>>>>
>>>>
>>>> Recién veo el mail de Juan Vuletich, en Dolphin tengo FloatArray
>>>> tambien. Calculo que en vez de variables de instancia podría tener un
>>>> array de estos en mis objetos y los accessors que apunten a cada una
>>>> de las posiciones del array. No se si te referis a que es posible ese
>>>> uso. Ja! no me imagino lo que tendría que testear...
>>>> Saludos
>>>>  GallegO
>>>
>>>
>>>
>>> Si, a eso me refiero. Incluso, si tenes las operaciones de FloatArray
>>> necesarias, durante los calculos no necesitas alocar Floats. Hacés
>>> directamente las cuentas con los FloatArray, y usando operaciones que
>>> sobreescriben los valores (en vez de crear instancias nuevas).
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>>
>
> Cheers,
> Juan Vuletich
>

[Juan]

Hola Gallego , gente

Gallego y que tal usar omnibase? tal vez no lo resuelva no se,  pero no allocarias memoria
ademas el omnibase te haria los proxy's y es muy performante, con limitaciones claro , péro
es una idea. ademas si tenes problemas con el table object podria ser una solucion,
no se Bruno tambien tiene experiencia con Omnibase, que pensas Bruno?.
salu2
jmdc

2012/5/3 GallegO <fxga...@gmail.com>

[Esteban A. Maringolo]

El 3 de mayo de 2012 18:19, Juan <smalltalk...@gmail.com> escribió:

Hola Gallego , gente

Gallego y que tal usar omnibase? tal vez no lo resuelva no se,  pero no allocarias memoria
ademas el omnibase te haria los proxy's y es muy performante, con limitaciones claro , péro
es una idea. ademas si tenes problemas con el table object podria ser una solucion,
no se Bruno tambien tiene experiencia con Omnibase, que pensas Bruno?.

¿Para qué usaríamos Omnibase?

Algo de experiencia con Omnibase tenemos, sobre todo con un repositorio de STS de unos 800MB y creciendo... 

Esteban A. Maringolo

 

[Juan Vuletich (mail lists)]

Quoting GallegO <fxga...@gmail.com>:

>> Yo no llamaría a Cuis "producto", ya que no se vende! Prefiero llamarlo
>> "proyecto".
>
> Ok :)
>
>> Una estrategia para hacer algo como lo que vos imaginás podría llegar a
>> entrar a mi "radar" si tuviera un problema y esa fuera la mejor solución. En
>> este caso, la solución que yo usaría es la que ya te sugerí; así que si
>> estuviera en tu lugar (pero usando Cuis), igual tampoco intentaría meter en
>> la VM lo que vos decís...

Algo que me olvide de aclarar... Yo para Cuis implemento lo que me
parece que es bueno que este en el sistema base. Si alguien mas quiere
implementar lo que vos proponias es muy bienvenido!

>> Yo te diría que pienses un ratito en lo que sugiero. La mejora en
>> performance sería muy grande (hablo por experiencia).
>
> Ok. Conoces alguna implementacion de la aritmética en estos External Float?

No para Dolphin... Cuis (y Squeak, y supongo que Pharo tambien) tienen
la clase FloatArray con metodos como #*=, etc.

Cheers,
Juan Vuletich

[Juan]

Gallego

Omnibase para usar un ODBTreeDictionary (no recuerdo exactamente el nombre) donde poner los floats, de manera tal que no los instanciarias en tu image.
ademas es rapido el accceso y son proxy ,esa fue la idea.
salu2
jmdc

2012/5/3 Juan Vuletich (mail lists) <juan...@jvuletich.org>

Saludos
 GallegO

clubSmalltalk+unsubscribe@googlegroups.com

http://www.clubSmalltalk.org

--
To post to this group, send email to clubSm...@googlegroups.com

To unsubscribe from this group, send email to clubSmalltalk+unsubscribe@googlegroups.com

http://www.clubSmalltalk.org

Cheers,
Juan Vuletich

--
To post to this group, send email to clubSm...@googlegroups.com

To unsubscribe from this group, send email to clubSmalltalk+unsubscribe@googlegroups.com

http://www.clubSmalltalk.org

[Angel Java Lopez]

Ah! Ahora entendi, no conocia las limitaciones de memoria de esas implementacions, gracias por el detalle.

Bien, si el tema es el consumo de memoria (y las entradas de la Object Table, en las implementaciones que usan OT, creo que Squeak no la usa, no?) se podria tener operaciones tipo

x *= y

x += 1.2

estas operaciones USARIAN COMO RESULTADO el mismo lugar/espacio ya reservado para x.

Claro, no es una solucion para ahora, porque implica tocar la VM (creo). Pero permitiria:

- Mantener los operadores *, + y demas como siempre

- Usar estos operadores en los casos que se necesita

Nos leemos!

Angel "Java" Lopez

2012/5/3 GallegO <fxga...@gmail.com>