[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 ?
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo- project-bounces@lists.gforge.inria.fr] 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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=C... ...Stan -- View this message in context: http://n2.nabble.com/Question-about-deepCopy-tp3859147p3923585.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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=C...
...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.
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=C...
...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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
arnaud Jean Baptiste -
Schwab,Wilhelm K -
Stan Shepherd -
Stéphane Ducasse