Xailer forum

Hola,
Aunque esto no es cosa de Xailer, me he encontrado con un problema
particular que no se si es el comportamiento correcto cuando se clonan
objetos.
El caso es que cuando hacemos clon := __objClone( objeto ) se clona el
objeto completo, pero si hay un objeto dentro del objeto clonado, no se
clona y al hacer cambios en las datas las modifica también en el objeto
original. ¿Esto es correcto?
Dejo un ejemplo en Xailer 2.0.18.
Saludos
Alf+.
--

No se si lo que hace __objClone() es el comportamiento correcto, pero he
dado con la solución implementando un método clone() en las clases.
La solución quedarí­a así­:
CLASS Objeto1
DATA dato1
DATA dato2
DATA objeto
METHOD new() CONSTRUCTOR
METHOD clone()
ENDCLASS
METHOD new() CLASS Objeto1
::dato1 := "Dato 1 del Objeto 1"
::dato2 := "Dato 2 del Objeto 1"
::objeto := objeto2():new()
RETURN self
METHOD clone() CLASS Objeto1
local o
o := __objClone( self )
o:objeto := ::objeto:clone()
RETURN o
//-----------------------------------------------------
CLASS Objeto2
DATA dato1
DATA dato2
METHOD new() CONSTRUCTOR
METHOD clone()
ENDCLASS
METHOD new() CLASS Objeto2
::dato1 := "Dato 1 objeto 2"
::dato2 := "Dato 2 objeto 2"
RETURN self
METHOD clone() CLASS Objeto2
local o
o := __objClone( self )
RETURN o
Saludos,
Alf+.
El 21/07/2012 21:50, José Alfonso Suárez Moreno escribió:
> Hola,
>
> Aunque esto no es cosa de Xailer, me he encontrado con un problema
> particular que no se si es el comportamiento correcto cuando se clonan
> objetos.
>
> El caso es que cuando hacemos clon := __objClone( objeto ) se clona el
> objeto completo, pero si hay un objeto dentro del objeto clonado, no se
> clona y al hacer cambios en las datas las modifica también en el objeto
> original. ¿Esto es correcto?
>
> Dejo un ejemplo en Xailer 2.0.18.
>
> Saludos
>
> Alf+.

Gracias José, viene bién tu aporte.
Saludo.

> No se si lo que hace __objClone() es el comportamiento correcto, pero he
> dado con la solución implementando un método clone() en las clases.
Me parece que esa es la solución ideal. No hay un 'comportamiento
correcto' de __objClone() porque probablemente lo que dice si es
correcto serí­a la semántica de la clase, y el contexto.
En el ejemplo que pones hay una data 'dato1'. ¿Que pasarí­a si dato1
fuese, por ejemplo, un handle de archivo? O más complejo aún, un handle
de windows. ¿Debe la clase clonar tambien esos objetos?
Y si la clase es una factura, con un oCliente, al clonar la factura no
deberí­a clonar el cliente... ¿o sí­?
Por eso le veo pinta de que es la propia clase la responsable de
implementar el comportamiento de lo que se considera un clone. Tengo una
clase que me hace de buffer de los registros de una dbf. Tiene un método
read que levanta los valores de los campos y guarda el recno() para
despues poder guardarlos. Y tiene un método clone(), que copia el buffer
interno (un array), poniendo a 0 el recno, ya que es un registro diferente.
Saludos

Hola Carlos,
Totalmente de acuerdo contigo en lo que dices. Debe ser responsabilidad
del programador decidir que cosas deben clonarse al clonar un objeto.
Saludos
Alf+.
El 25/07/2012 10:38, Carlos Mora escribió:
>> No se si lo que hace __objClone() es el comportamiento correcto, pero he
>> dado con la solución implementando un método clone() en las clases.
>
> Me parece que esa es la solución ideal. No hay un 'comportamiento
> correcto' de __objClone() porque probablemente lo que dice si es
> correcto serí­a la semántica de la clase, y el contexto.
> En el ejemplo que pones hay una data 'dato1'. ¿Que pasarí­a si dato1
> fuese, por ejemplo, un handle de archivo? O más complejo aún, un handle
> de windows. ¿Debe la clase clonar tambien esos objetos?
> Y si la clase es una factura, con un oCliente, al clonar la factura no
> deberí­a clonar el cliente... ¿o sí­?
> Por eso le veo pinta de que es la propia clase la responsable de
> implementar el comportamiento de lo que se considera un clone. Tengo una
> clase que me hace de buffer de los registros de una dbf. Tiene un método
> read que levanta los valores de los campos y guarda el recno() para
> despues poder guardarlos. Y tiene un método clone(), que copia el buffer
> interno (un array), poniendo a 0 el recno, ya que es un registro diferente.
>
> Saludos
>
>

Bueno lo ideal en POO serí­a tener una interface TCloneable cuyo método
más importante y de obligada implementación serí­a ::Clone() para usarlo así­:
oObjClon := obj:clone()
Pero si se quiere hacer a nivel de función se podrí­a crear una que fuera
recursiva y además que sepa tratar array y objetos para automatizar el
proceso.
oObjClon := XClone( obj )
El 25/07/2012 11:13, José Alfonso Suárez Moreno escribió:
> Hola Carlos,
>
> Totalmente de acuerdo contigo en lo que dices. Debe ser responsabilidad
> del programador decidir que cosas deben clonarse al clonar un objeto.
>
> Saludos
>
> Alf+.
>
> El 25/07/2012 10:38, Carlos Mora escribió:
>>> No se si lo que hace __objClone() es el comportamiento correcto, pero he
>>> dado con la solución implementando un método clone() en las clases.
>>
>> Me parece que esa es la solución ideal. No hay un 'comportamiento
>> correcto' de __objClone() porque probablemente lo que dice si es
>> correcto serí­a la semántica de la clase, y el contexto.
>> En el ejemplo que pones hay una data 'dato1'. ¿Que pasarí­a si dato1
>> fuese, por ejemplo, un handle de archivo? O más complejo aún, un handle
>> de windows. ¿Debe la clase clonar tambien esos objetos?
>> Y si la clase es una factura, con un oCliente, al clonar la factura no
>> deberí­a clonar el cliente... ¿o sí­?
>> Por eso le veo pinta de que es la propia clase la responsable de
>> implementar el comportamiento de lo que se considera un clone. Tengo una
>> clase que me hace de buffer de los registros de una dbf. Tiene un método
>> read que levanta los valores de los campos y guarda el recno() para
>> despues poder guardarlos. Y tiene un método clone(), que copia el buffer
>> interno (un array), poniendo a 0 el recno, ya que es un registro
>> diferente.
>>
>> Saludos
>>
>>
>

Buenos quizás serí­a interesante como hace Python;
o := oBjeto.Clone(), clona los atributos, pero las referencias a los
objetos se comparten, tal y como hace Harbour.
o := oBjeto.DeepClone(), hace una clonacion de todos los objetos.
De esta manera, el programador no tiene que hacer ninguna historia rara
ni implementar nada, usa lo que más le conviene.
Saludos
Rafa Carmona
El 26/07/2012 0:45, Manu escribió:
> Bueno lo ideal en POO serí­a tener una interface TCloneable cuyo método
> más importante y de obligada implementación serí­a ::Clone() para usarlo
> así­:
> oObjClon := obj:clone()
>
> Pero si se quiere hacer a nivel de función se podrí­a crear una que fuera
> recursiva y además que sepa tratar array y objetos para automatizar el
> proceso.
> oObjClon := XClone( obj )
>
> El 25/07/2012 11:13, José Alfonso Suárez Moreno escribió:
>> Hola Carlos,
>>
>> Totalmente de acuerdo contigo en lo que dices. Debe ser responsabilidad
>> del programador decidir que cosas deben clonarse al clonar un objeto.
>>
>> Saludos
>>
>> Alf+.
>>
>> El 25/07/2012 10:38, Carlos Mora escribió:
>>>> No se si lo que hace __objClone() es el comportamiento correcto,
>>>> pero he
>>>> dado con la solución implementando un método clone() en las clases.
>>>
>>> Me parece que esa es la solución ideal. No hay un 'comportamiento
>>> correcto' de __objClone() porque probablemente lo que dice si es
>>> correcto serí­a la semántica de la clase, y el contexto.
>>> En el ejemplo que pones hay una data 'dato1'. ¿Que pasarí­a si dato1
>>> fuese, por ejemplo, un handle de archivo? O más complejo aún, un handle
>>> de windows. ¿Debe la clase clonar tambien esos objetos?
>>> Y si la clase es una factura, con un oCliente, al clonar la factura no
>>> deberí­a clonar el cliente... ¿o sí­?
>>> Por eso le veo pinta de que es la propia clase la responsable de
>>> implementar el comportamiento de lo que se considera un clone. Tengo una
>>> clase que me hace de buffer de los registros de una dbf. Tiene un método
>>> read que levanta los valores de los campos y guarda el recno() para
>>> despues poder guardarlos. Y tiene un método clone(), que copia el buffer
>>> interno (un array), poniendo a 0 el recno, ya que es un registro
>>> diferente.
>>>
>>> Saludos
>>>
>>>
>>
>