Question about deepCopy,

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about deepCopy,

Jean Baptiste Arnaud

question:

deepCopy have this behavior :
- copy self.
- then send deepCopy on all instance var.

this behavior, make infinite loop when  a object have instance  
variable which reference to himself or more longer cycle.

Why don't replace deepCopy by veryDeepCopy, same behavior but copy  
each object only once (create collection and keep reference).
performance issue ?





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Question about deepCopy,

Schwab,Wilhelm K
I'm going to briefly be a wise-guy to a (well intentioned) purpose.  You appear to be suggesting that we call #deepCopy something else, and then fix it.

One might drag the fix into #deepCopy??  But years ago now, #deepCopy fell from grace, perhaps for good reason.  What I recall seeing in its place was #postCopy that can be overriden to ensure a distinct copy; that seemed to be in contrast to #shallowCopy.

This deserves some attention to ensure that we do the correct thing.

Bill



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of arnaud Jean Baptiste
Sent: Tuesday, October 20, 2009 10:07 AM
To: Pharo Development
Subject: [Pharo-project] Question about deepCopy,


question:

deepCopy have this behavior :
- copy self.
- then send deepCopy on all instance var.

this behavior, make infinite loop when  a object have instance variable which reference to himself or more longer cycle.

Why don't replace deepCopy by veryDeepCopy, same behavior but copy each object only once (create collection and keep reference).
performance issue ?





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Question about deepCopy,

Jean Baptiste Arnaud
Hi,
at the beginning, it is a simply question, not a suggest of features.

And have a answer to my question, why we keep that, for performance?
In this case when perform a #deepCopy how ensure, in the system we  
don't have cycle between self and instance var (recursively)?
the behavior of #deepCopy is it really relevant (not the name) ?

Then,
I don't suggest to rename #deepCopy, i suggest to replace the behavior  
of #deepCopy by #veryDeepCopy behavior.

Finally i just want to understand the reason, why we keep that? If we  
keep, it certainly for good reason, which?
I just want to have a better understanding of the system.

PS: I ask this question because i search about issue 521. And  
#deepCopy create infinite loop because there are a cycle.



On Oct 21, 2009, at 1:26 AM, Schwab,Wilhelm K wrote:

> I'm going to briefly be a wise-guy to a (well intentioned) purpose.  
> You appear to be suggesting that we call #deepCopy something else,  
> and then fix it.
>
> One might drag the fix into #deepCopy??  But years ago now,  
> #deepCopy fell from grace, perhaps for good reason.  What I recall  
> seeing in its place was #postCopy that can be overriden to ensure a  
> distinct copy; that seemed to be in contrast to #shallowCopy.
>
> This deserves some attention to ensure that we do the correct thing.
>
> Bill
>
>
>
> -----Original Message-----
> From: [hidden email] [mailto:pharo-
> [hidden email]] On Behalf Of arnaud Jean  
> Baptiste
> Sent: Tuesday, October 20, 2009 10:07 AM
> To: Pharo Development
> Subject: [Pharo-project] Question about deepCopy,
>
>
> question:
>
> deepCopy have this behavior :
> - copy self.
> - then send deepCopy on all instance var.
>
> this behavior, make infinite loop when  a object have instance  
> variable which reference to himself or more longer cycle.
>
> Why don't replace deepCopy by veryDeepCopy, same behavior but copy  
> each object only once (create collection and keep reference).
> performance issue ?
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Question about deepCopy,

Stan Shepherd
arnaud Jean Baptiste wrote
I don't suggest to rename #deepCopy, i suggest to replace the behavior  
of #deepCopy by #veryDeepCopy behavior.
From my observation, the two do not have identical behaviour. In my own case, I need the behaviour of deepCopy to avoid copying a very large object unnecessarily; for now I have a specific method for the object copyWithoutCircularity.

There are 44 senders of deepCopy, which would need testing.

Another solution is to rewrite deepCopy like veryDeepCopy, to have a copier object. This needs another method on Object, deepCopyWith:

I'm happy to implement a solution, given a consensus on the best way to do this.

I have created a general test case for this situation, attached to issue 521

http://pharo.googlecode.com/issues/attachment?aid=7298911011553982520&name=CircularInstVarTest.st

...Stan
Reply | Threaded
Open this post in threaded view
|

Re: Question about deepCopy,

Stan Shepherd
I meant to say, maybe deepCopy should just be deprecated?

Stan Shepherd wrote
arnaud Jean Baptiste wrote
I don't suggest to rename #deepCopy, i suggest to replace the behavior  
of #deepCopy by #veryDeepCopy behavior.
From my observation, the two do not have identical behaviour. In my own case, I need the behaviour of deepCopy to avoid copying a very large object unnecessarily; for now I have a specific method for the object copyWithoutCircularity.

There are 44 senders of deepCopy, which would need testing.

Another solution is to rewrite deepCopy like veryDeepCopy, to have a copier object. This needs another method on Object, deepCopyWith:

I'm happy to implement a solution, given a consensus on the best way to do this.

I have created a general test case for this situation, attached to issue 521

http://pharo.googlecode.com/issues/attachment?aid=7298911011553982520&name=CircularInstVarTest.st

...Stan
Reply | Threaded
Open this post in threaded view
|

Re: Question about deepCopy,

Stéphane Ducasse
indeed this is strange. I would be nice to have some tests to cover  
the existing situations.

Stef

On Oct 31, 2009, at 12:49 PM, Stan Shepherd wrote:

>
> I meant to say, maybe deepCopy should just be deprecated?
>
>
> Stan Shepherd wrote:
>>
>>
>> arnaud Jean Baptiste wrote:
>>>
>>>
>>> I don't suggest to rename #deepCopy, i suggest to replace the  
>>> behavior
>>> of #deepCopy by #veryDeepCopy behavior.
>>>
>>
>> From my observation, the two do not have identical behaviour. In my  
>> own
>> case, I need the behaviour of deepCopy to avoid copying a very large
>> object unnecessarily; for now I have a specific method for the object
>> copyWithoutCircularity.
>>
>> There are 44 senders of deepCopy, which would need testing.
>>
>> Another solution is to rewrite deepCopy like veryDeepCopy, to have a
>> copier object. This needs another method on Object, deepCopyWith:
>>
>> I'm happy to implement a solution, given a consensus on the best  
>> way to do
>> this.
>>
>> I have created a general test case for this situation, attached to  
>> issue
>> 521
>>
>> http://pharo.googlecode.com/issues/attachment?aid=7298911011553982520&name=CircularInstVarTest.st
>>
>> ...Stan
>>
>
> --
> View this message in context: http://n2.nabble.com/Question-about-deepCopy-tp3859147p3923589.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project