[Pharo-project] clone vs shallowCopy
Hi, I found the clone primitive method in the Object class. Its behavior looks the same as shallowCopy. Actually, shallowCopy just sends basicShallowCopy wich calls the same primitive as clone (primitive 148). a1 := Array with: Object new. a2 := a1 clone. a1 == a2. "--->false" a1 first == a2 first. "--->true" When I look to senders (in a pharo-dev 12.2) I find the following: -62 senders of clone. -2 senders of basicShallowCopy -66 senders of shallowCopy Looking to implementors I found: -9 implementors of shallowCopy (all are kernel classes) -1 implementor of basicShallowCopy (not surprizing) -6 implementors of clone (all are kernel classes) Most implementors of clone and shallowCopy are different. Yet, implementations done by same classes are the same behavior. Other implementations of clone answer self, because there are for objects that should/can't be copied (e.g. SmallInteger, Character). So, I suggest to remove clone and use shallowCopy instead (better/more precise name). Anybody has any reeason against? Otherwise, I'll do it. Noury
On Tue, 12 Jan 2010, Bouraqadi Noury wrote:
Hi,
I found the clone primitive method in the Object class. Its behavior looks the same as shallowCopy. Actually, shallowCopy just sends basicShallowCopy wich calls the same primitive as clone (primitive 148).
I wonder what image do you use. In a standard image #clone is primitive only, while #shallowCopy tries to copy the object if the primitive fails. #basicShallowCopy doesn't exist. Levente
a1 := Array with: Object new. a2 := a1 clone. a1 == a2. "--->false" a1 first == a2 first. "--->true"
When I look to senders (in a pharo-dev 12.2) I find the following: -62 senders of clone. -2 senders of basicShallowCopy -66 senders of shallowCopy
Looking to implementors I found: -9 implementors of shallowCopy (all are kernel classes) -1 implementor of basicShallowCopy (not surprizing) -6 implementors of clone (all are kernel classes)
Most implementors of clone and shallowCopy are different. Yet, implementations done by same classes are the same behavior. Other implementations of clone answer self, because there are for objects that should/can't be copied (e.g. SmallInteger, Character).
So, I suggest to remove clone and use shallowCopy instead (better/more precise name). Anybody has any reeason against? Otherwise, I'll do it.
Noury
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/1/12 Levente Uzonyi <leves@elte.hu>:
On Tue, 12 Jan 2010, Bouraqadi Noury wrote:
Hi,
I found the clone primitive method in the Object class. Its behavior looks the same as shallowCopy. Actually, shallowCopy just sends basicShallowCopy wich calls the same primitive as clone (primitive 148).
I wonder what image do you use. In a standard image #clone is primitive only, while #shallowCopy tries to copy the object if the primitive fails. #basicShallowCopy doesn't exist.
I am using #clone, to be 100% sure that i cloning object primitively, without additional logic, which #shallowCopy may introduce.
Levente
a1 := Array with: Object new. a2 := a1 clone. a1 == a2. "--->false" a1 first == a2 first. "--->true"
When I look to senders (in a pharo-dev 12.2) I find the following: -62 senders of clone. -2 senders of basicShallowCopy -66 senders of shallowCopy
Looking to implementors I found: -9 implementors of shallowCopy (all are kernel classes) -1 implementor of basicShallowCopy (not surprizing) -6 implementors of clone (all are kernel classes)
Most implementors of clone and shallowCopy are different. Yet, implementations done by same classes are the same behavior. Other implementations of clone answer self, because there are for objects that should/can't be copied (e.g. SmallInteger, Character).
So, I suggest to remove clone and use shallowCopy instead (better/more precise name). Anybody has any reeason against? Otherwise, I'll do it.
Noury
_______________________________________________ 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
-- Best regards, Igor Stasenko AKA sig.
Hi,
I found the clone primitive method in the Object class. Its behavior looks the same as shallowCopy. Actually, shallowCopy just sends basicShallowCopy wich calls the same primitive as clone (primitive 148).
I wonder what image do you use. In a standard image #clone is primitive only, while #shallowCopy tries to copy the object if the primitive fails. #basicShallowCopy doesn't exist.
I am using #clone, to be 100% sure that i cloning object primitively, without additional logic, which #shallowCopy may introduce.
shallowCopy should not overriden this is postCopy that should. how can you be sure that clone is not overriden? I have the same code for shallowCopy and clone and it would make sense to remove one and may to add that this methods should not be overridden (except by system classes) Stef
2010/1/12 Bouraqadi Noury <bouraqadi@gmail.com>:
Hi,
I found the clone primitive method in the Object class. Its behavior looks the same as shallowCopy. Actually, shallowCopy just sends basicShallowCopy wich calls the same primitive as clone (primitive 148).
a1 := Array with: Object new. a2 := a1 clone. a1 == a2. "--->false" a1 first == a2 first. "--->true"
When I look to senders (in a pharo-dev 12.2) I find the following: -62 senders of clone. -2 senders of basicShallowCopy -66 senders of shallowCopy
Looking to implementors I found: -9 implementors of shallowCopy (all are kernel classes) -1 implementor of basicShallowCopy (not surprizing) -6 implementors of clone (all are kernel classes)
Most implementors of clone and shallowCopy are different. Yet, implementations done by same classes are the same behavior. Other implementations of clone answer self, because there are for objects that should/can't be copied (e.g. SmallInteger, Character).
So, I suggest to remove clone and use shallowCopy instead (better/more precise name). Anybody has any reeason against? Otherwise, I'll do it.
Noury
basicShallowCopy was a workaround for some badly written copy in OrderedCollection. I did add it, then removed it in squeak/trunk. I suggest following the same path in Pharo. You can also remove Float>>shallowCopy since super would perform as well. I corrected it recently for fun, but it should better be removed (was removed from squeak/trunk). For clone, I don't know. Nicolas
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
- #copy is the normal copy operation. It should be used by default and never overridden. It calls #postCopy that can be overridden to have class specific copy semantics. - #shallowCopy does a shallow copy. It should never be overridden and only be used if you want to get these very specific semantics. - #deepCopy does a deep copy. It should never be overridden and only be used if you want to get these very specific semantics. - #clone comes from eToys and Morphic (AFAIK). It implements some other copy semantics than #copy. I don't think that anybody should call this method, other than code that depends on this particular copy behavior. This is exactly the same problematic as with #=. There can't be just one #=. Other clients might consider other things when comparing objects. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Tue, 12 Jan 2010, Lukas Renggli wrote:
- #copy is the normal copy operation. It should be used by default and never overridden. It calls #postCopy that can be overridden to have class specific copy semantics.
- #shallowCopy does a shallow copy. It should never be overridden and only be used if you want to get these very specific semantics.
- #deepCopy does a deep copy. It should never be overridden and only be used if you want to get these very specific semantics.
It doesn't handle cycles, #veryDeepCopy does.
- #clone comes from eToys and Morphic (AFAIK). It implements some other copy semantics than #copy. I don't think that anybody should call this method, other than code that depends on this particular copy behavior.
From Morphic.
Levente
This is exactly the same problematic as with #=. There can't be just one #=. Other clients might consider other things when comparing objects.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
http://code.google.com/p/pharo/issues/list?thanks=1789 I do not understand why we need deepCopy and why deepCopy does not implement the veryDeepCopy semantics? On Jan 12, 2010, at 1:41 PM, Levente Uzonyi wrote:
- #copy is the normal copy operation. It should be used by default and never overridden. It calls #postCopy that can be overridden to have class specific copy semantics.
- #shallowCopy does a shallow copy. It should never be overridden and only be used if you want to get these very specific semantics.
- #deepCopy does a deep copy. It should never be overridden and only be used if you want to get these very specific semantics.
It doesn't handle cycles, #veryDeepCopy does.
- #clone comes from eToys and Morphic (AFAIK). It implements some other copy semantics than #copy. I don't think that anybody should call this method, other than code that depends on this particular copy behavior.
From Morphic.
Levente
This is exactly the same problematic as with #=. There can't be just one #=. Other clients might consider other things when comparing objects.
2010/1/12 Stéphane Ducasse <stephane.ducasse@inria.fr>:
http://code.google.com/p/pharo/issues/list?thanks=1789
I do not understand why we need deepCopy and why deepCopy does not implement the veryDeepCopy semantics?
On Jan 12, 2010, at 1:41 PM, Levente Uzonyi wrote:
IMO it's the historical st80 deepCopy. Nicolas
- #copy is the normal copy operation. It should be used by default and never overridden. It calls #postCopy that can be overridden to have class specific copy semantics.
- #shallowCopy does a shallow copy. It should never be overridden and only be used if you want to get these very specific semantics.
- #deepCopy does a deep copy. It should never be overridden and only be used if you want to get these very specific semantics.
It doesn't handle cycles, #veryDeepCopy does.
- #clone comes from eToys and Morphic (AFAIK). It implements some other copy semantics than #copy. I don't think that anybody should call this method, other than code that depends on this particular copy behavior.
From Morphic.
Levente
This is exactly the same problematic as with #=. There can't be just one #=. Other clients might consider other things when comparing objects.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Nicolas Cellier wrote:
2010/1/12 Stéphane Ducasse <stephane.ducasse@inria.fr>:
http://code.google.com/p/pharo/issues/list?thanks=1789
I do not understand why we need deepCopy and why deepCopy does not implement the veryDeepCopy semantics?
On Jan 12, 2010, at 1:41 PM, Levente Uzonyi wrote:
IMO it's the historical st80 deepCopy.
Probably so. FWIW, VW got rid of #deepCopy years ago; the only remnant is Object>>deepCopy, which is implemented as 'self copy'. This was probably a good choice, since deepCopy's semantics are problematic and not often useful. Regards, -Martin
Stéphane Ducasse wrote:
http://code.google.com/p/pharo/issues/list?thanks=1789
I do not understand why we need deepCopy and why deepCopy does not implement the veryDeepCopy semantics?
On Jan 12, 2010, at 1:41 PM, Levente Uzonyi wrote:
- #copy is the normal copy operation. It should be used by default and never overridden. It calls #postCopy that can be overridden to have class specific copy semantics.
- #shallowCopy does a shallow copy. It should never be overridden and only be used if you want to get these very specific semantics.
- #deepCopy does a deep copy. It should never be overridden and only be used if you want to get these very specific semantics.
It doesn't handle cycles, #veryDeepCopy does.
see discussion for http://code.google.com/p/pharo/issues/detail?id=521. The behaviors are different. So #deepCopy perhaps should go, but it is not safe to assume that #deepCopy can just be replaced with #veryDeepCopy Stan -- View this message in context: http://n2.nabble.com/clone-vs-shallowCopy-tp4290815p4293752.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Tue, 12 Jan 2010, Stéphane Ducasse wrote:
http://code.google.com/p/pharo/issues/list?thanks=1789
I do not understand why we need deepCopy and why deepCopy does not implement the veryDeepCopy semantics?
Because it's lightweight compared to #veryDeepCopy. Levente
On Jan 12, 2010, at 1:41 PM, Levente Uzonyi wrote:
- #copy is the normal copy operation. It should be used by default and never overridden. It calls #postCopy that can be overridden to have class specific copy semantics.
- #shallowCopy does a shallow copy. It should never be overridden and only be used if you want to get these very specific semantics.
- #deepCopy does a deep copy. It should never be overridden and only be used if you want to get these very specific semantics.
It doesn't handle cycles, #veryDeepCopy does.
- #clone comes from eToys and Morphic (AFAIK). It implements some other copy semantics than #copy. I don't think that anybody should call this method, other than code that depends on this particular copy behavior.
From Morphic.
Levente
This is exactly the same problematic as with #=. There can't be just one #=. Other clients might consider other things when comparing objects.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Jan 12, 2010, at 1:20 PM, Lukas Renggli wrote:
- #copy is the normal copy operation. It should be used by default and never overridden. It calls #postCopy that can be overridden to have class specific copy semantics.
- #shallowCopy does a shallow copy. It should never be overridden and only be used if you want to get these very specific semantics.
- #deepCopy does a deep copy. It should never be overridden and only be used if you want to get these very specific semantics.
- #clone comes from eToys and Morphic (AFAIK). It implements some other copy semantics than #copy. I don't think that anybody should call this method, other than code that depends on this particular copy behavior.
we should copy that in Object class comment and all the methods where do you see that it is morphic related for me clone is only implemented on character, Boolean, Object, SMalltInt symbol, UndefinedObject
This is exactly the same problematic as with #=. There can't be just one #=. Other clients might consider other things when comparing objects.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
where do you see that it is morphic related for me clone is only implemented on character, Boolean, Object, SMalltInt symbol, UndefinedObject
I am wrong. Forget what I said about #clone. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
I think that #clone comes from Self or other prototype-based things. I prefer to use it instead of #shallowCopy, because as to me its more concise and more precise term for such operation - creating a 'bit-identical' copy of object. 2010/1/12 Lukas Renggli <renggli@gmail.com>:
where do you see that it is morphic related for me clone is only implemented on character, Boolean, Object, SMalltInt symbol, UndefinedObject
I am wrong. Forget what I said about #clone.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Jan 12, 2010, at 8:03 PM, Igor Stasenko wrote:
I think that #clone comes from Self or other prototype-based things.
I prefer to use it instead of #shallowCopy, because as to me its more concise and more precise term for such operation - creating a 'bit-identical' copy of object.
but shallowCopy means what is does while clone would be more like veryDeepCopy but this is not... So I would like to remove it.
2010/1/12 Lukas Renggli <renggli@gmail.com>:
where do you see that it is morphic related for me clone is only implemented on character, Boolean, Object, SMalltInt symbol, UndefinedObject
I am wrong. Forget what I said about #clone.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/1/12 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Jan 12, 2010, at 8:03 PM, Igor Stasenko wrote:
I think that #clone comes from Self or other prototype-based things.
I prefer to use it instead of #shallowCopy, because as to me its more concise and more precise term for such operation - creating a 'bit-identical' copy of object.
but shallowCopy means what is does while clone would be more like veryDeepCopy but this is not...
hmm.. never thought in that way. for me, clone is a most basic copy method, which cloning a single object, means that its faar away from veryDeep one. AFAIK, there's also a way to clone object without even changing its identity hash.
So I would like to remove it.
2010/1/12 Lukas Renggli <renggli@gmail.com>:
where do you see that it is morphic related for me clone is only implemented on character, Boolean, Object, SMalltInt symbol, UndefinedObject
I am wrong. Forget what I said about #clone.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ 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
-- Best regards, Igor Stasenko AKA sig.
On Tue, 12 Jan 2010, Stéphane Ducasse wrote:
On Jan 12, 2010, at 1:20 PM, Lukas Renggli wrote:
- #copy is the normal copy operation. It should be used by default and never overridden. It calls #postCopy that can be overridden to have class specific copy semantics.
- #shallowCopy does a shallow copy. It should never be overridden and only be used if you want to get these very specific semantics.
- #deepCopy does a deep copy. It should never be overridden and only be used if you want to get these very specific semantics.
- #clone comes from eToys and Morphic (AFAIK). It implements some other copy semantics than #copy. I don't think that anybody should call this method, other than code that depends on this particular copy behavior.
we should copy that in Object class comment and all the methods
where do you see that it is morphic related for me clone is only implemented on character, Boolean, Object, SMalltInt symbol, UndefinedObject
Back in the old days, Squeak 1.1 didn't have primitive 148 (which is now used by both #shallowCopy and #clone). #shallowCopy was the way to create a "one-level copy" of an Object. It had the same code as today, but with no primitive. Primitive 148 was introduced somewhere between 1.1 and 1.19 (note that 1.2 came after 1.19). 1.19 (and probably earlier versions, but not 1.1) had #clone which was primitive only and #shallowCopy which didn't use the primitive. Morphic was being ported to Squeak at the time and it was the only user of #clone. Morphs were copied by #clone which was pretty fast, while other objects used #shallowCopy. Later the use of #clone started to spread, until primitive 148 was added to #shallowCopy. Sends of #clone were replaced with #shallowCopy and #copy, but #clone was kept, probably for backwards compatibility. #clone and #shallowCopy have a difference in their semantics. If the vm cannot allocate enough space for the new object, #clone raises an error immediately, while #shallowCopy signals the low space semaphore, so the image or the user can do something, then retries the copying. Levente
This is exactly the same problematic as with #=. There can't be just one #=. Other clients might consider other things when comparing objects.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ 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
Thanks for this historical point. Cheers, Alexandre On 12 Jan 2010, at 23:25, Levente Uzonyi wrote:
On Tue, 12 Jan 2010, Stéphane Ducasse wrote:
On Jan 12, 2010, at 1:20 PM, Lukas Renggli wrote:
- #copy is the normal copy operation. It should be used by default and never overridden. It calls #postCopy that can be overridden to have class specific copy semantics.
- #shallowCopy does a shallow copy. It should never be overridden and only be used if you want to get these very specific semantics.
- #deepCopy does a deep copy. It should never be overridden and only be used if you want to get these very specific semantics.
- #clone comes from eToys and Morphic (AFAIK). It implements some other copy semantics than #copy. I don't think that anybody should call this method, other than code that depends on this particular copy behavior.
we should copy that in Object class comment and all the methods
where do you see that it is morphic related for me clone is only implemented on character, Boolean, Object, SMalltInt symbol, UndefinedObject
Back in the old days, Squeak 1.1 didn't have primitive 148 (which is now used by both #shallowCopy and #clone). #shallowCopy was the way to create a "one-level copy" of an Object. It had the same code as today, but with no primitive. Primitive 148 was introduced somewhere between 1.1 and 1.19 (note that 1.2 came after 1.19). 1.19 (and probably earlier versions, but not 1.1) had #clone which was primitive only and #shallowCopy which didn't use the primitive. Morphic was being ported to Squeak at the time and it was the only user of #clone. Morphs were copied by #clone which was pretty fast, while other objects used #shallowCopy. Later the use of #clone started to spread, until primitive 148 was added to #shallowCopy. Sends of #clone were replaced with #shallowCopy and #copy, but #clone was kept, probably for backwards compatibility.
#clone and #shallowCopy have a difference in their semantics. If the vm cannot allocate enough space for the new object, #clone raises an error immediately, while #shallowCopy signals the low space semaphore, so the image or the user can do something, then retries the copying.
Levente
This is exactly the same problematic as with #=. There can't be just one #=. Other clients might consider other things when comparing objects.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
#clone and #shallowCopy have a difference in their semantics. If the vm cannot allocate enough space for the new object, #clone raises an error immediately, while #shallowCopy signals the low space semaphore, so the image or the user can do something, then retries the copying.
Do we really need that? It would be cool to merge #clone and #shallowCopy, and all the different #deepCopy* instances. Also the implementation of #deepCopy might need some cleanup, it seems to be rather complicated for such a trivial task of copying a object graph. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
I admit I have never fully understood the concern, but Lewis' Art and Science makes reference to flaws in #deepCopy. Not much to go on, but pg. 60 in my copy. It is a good book, so I do not easily dismiss what he says. At around the time I saw that, #postCopy came to my attention - connection??? Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Wednesday, January 13, 2010 2:54 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] clone vs shallowCopy
#clone and #shallowCopy have a difference in their semantics. If the vm cannot allocate enough space for the new object, #clone raises an error immediately, while #shallowCopy signals the low space semaphore, so the image or the user can do something, then retries the copying.
Do we really need that? It would be cool to merge #clone and #shallowCopy, and all the different #deepCopy* instances. Also the implementation of #deepCopy might need some cleanup, it seems to be rather complicated for such a trivial task of copying a object graph. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Yeah so I accept any code and else we will do it slowly step by step. On Jan 13, 2010, at 8:54 AM, Lukas Renggli wrote:
#clone and #shallowCopy have a difference in their semantics. If the vm cannot allocate enough space for the new object, #clone raises an error immediately, while #shallowCopy signals the low space semaphore, so the image or the user can do something, then retries the copying.
Do we really need that?
It would be cool to merge #clone and #shallowCopy, and all the different #deepCopy* instances. Also the implementation of #deepCopy might need some cleanup, it seems to be rather complicated for such a trivial task of copying a object graph.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, 13 Jan 2010, Lukas Renggli wrote:
#clone and #shallowCopy have a difference in their semantics. If the vm cannot allocate enough space for the new object, #clone raises an error immediately, while #shallowCopy signals the low space semaphore, so the image or the user can do something, then retries the copying.
Do we really need that?
I think #shallowCopy is enough.
It would be cool to merge #clone and #shallowCopy, and all the different #deepCopy* instances. Also the implementation of #deepCopy might need some cleanup, it seems to be rather complicated for such a trivial task of copying a object graph.
The implementation of #deepCopy seems to be pretty straightforward. I wonder how it could be simpler. Levente
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
It would be cool to merge #clone and #shallowCopy, and all the different #deepCopy* instances. Also the implementation of #deepCopy might need some cleanup, it seems to be rather complicated for such a trivial task of copying a object graph.
The implementation of #deepCopy seems to be pretty straightforward. I wonder how it could be simpler.
It doesn't handle recursion, which makes it pretty useless. I would suggest something like: deepCopy ^ self deepCopy: IdentityDictionary new deepCopy: anIdentityDictionary | copy | anIdentityDictionary at: self ifPresent: [ :value | ^ value ]. copy := anIdentityDictionary at: self put: self shallowCopy preDeepCopy. " copy all the variables of copy using 'var deepCopy: anIdentityDictionary' " ^ copy postDeepCopy -- Lukas Renggli http://www.lukas-renggli.ch
On Wed, 13 Jan 2010, Lukas Renggli wrote:
It would be cool to merge #clone and #shallowCopy, and all the different #deepCopy* instances. Also the implementation of #deepCopy might need some cleanup, it seems to be rather complicated for such a trivial task of copying a object graph.
The implementation of #deepCopy seems to be pretty straightforward. I wonder how it could be simpler.
It doesn't handle recursion, which makes it pretty useless.
That's what #veryDeepCopy does, though it does it in a more complicated way. #deepCopy has the advantage of being simple and fast. Levente
I would suggest something like:
deepCopy ^ self deepCopy: IdentityDictionary new
deepCopy: anIdentityDictionary | copy | anIdentityDictionary at: self ifPresent: [ :value | ^ value ]. copy := anIdentityDictionary at: self put: self shallowCopy preDeepCopy. " copy all the variables of copy using 'var deepCopy: anIdentityDictionary' " ^ copy postDeepCopy
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
It doesn't handle recursion, which makes it pretty useless.
That's what #veryDeepCopy does, though it does it in a more complicated way. #deepCopy has the advantage of being simple and fast.
And useless. I've never used it. If you change something here, it subtly breaks something there. I suggest everybody to have a quick look at VW: - they have #copy and #postCopy as we do - they have #shallowCopy that is used from #copy as we do - they have #dcopy (what a horrible name) that is implemented in a similar way to what I suggested for #deepCopy There is nothing else. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Lukas Renggli a écrit :
I suggest everybody to have a quick look at VW: - they have #copy and #postCopy as we do - they have #shallowCopy that is used from #copy as we do - they have #dcopy (what a horrible name) that is implemented in a similar way to what I suggested for #deepCopy
There is nothing else.
yes, I think we should adopt this with (dcopy -> deepCopy). Alain
Lukas
+1 I cannot imagine that they got dcopy (amazingly bad name) Stef On Jan 13, 2010, at 9:53 AM, Alain Plantec wrote:
Lukas Renggli a écrit :
I suggest everybody to have a quick look at VW: - they have #copy and #postCopy as we do - they have #shallowCopy that is used from #copy as we do - they have #dcopy (what a horrible name) that is implemented in a similar way to what I suggested for #deepCopy
There is nothing else.
yes, I think we should adopt this with (dcopy -> deepCopy). Alain
Lukas
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
any bunch of cool tests before hacking? On Jan 13, 2010, at 9:53 AM, Alain Plantec wrote:
Lukas Renggli a écrit :
I suggest everybody to have a quick look at VW: - they have #copy and #postCopy as we do - they have #shallowCopy that is used from #copy as we do - they have #dcopy (what a horrible name) that is implemented in a similar way to what I suggested for #deepCopy
There is nothing else.
yes, I think we should adopt this with (dcopy -> deepCopy). Alain
Lukas
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse wrote:
any bunch of cool tests before hacking?
On Jan 13, 2010, at 9:53 AM, Alain Plantec wrote:
Lukas Renggli a écrit :
I suggest everybody to have a quick look at VW: - they have #copy and #postCopy as we do - they have #shallowCopy that is used from #copy as we do - they have #dcopy (what a horrible name) that is implemented in a similar way to what I suggested for #deepCopy
There is nothing else.
yes, I think we should adopt this with (dcopy -> deepCopy). Alain
Lukas
there's one (not a bunch) at: http://pharo.googlecode.com/issues/attachment?aid=7298911011553982520&name=C... -- View this message in context: http://n2.nabble.com/clone-vs-shallowCopy-tp4290815p4348552.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Thanks I linked the two issues On Jan 13, 2010, at 2:33 PM, Stan Shepherd wrote:
Stéphane Ducasse wrote:
any bunch of cool tests before hacking?
On Jan 13, 2010, at 9:53 AM, Alain Plantec wrote:
Lukas Renggli a écrit :
I suggest everybody to have a quick look at VW: - they have #copy and #postCopy as we do - they have #shallowCopy that is used from #copy as we do - they have #dcopy (what a horrible name) that is implemented in a similar way to what I suggested for #deepCopy
There is nothing else.
yes, I think we should adopt this with (dcopy -> deepCopy). Alain
Lukas
there's one (not a bunch) at: http://pharo.googlecode.com/issues/attachment?aid=7298911011553982520&name=C... -- View this message in context: http://n2.nabble.com/clone-vs-shallowCopy-tp4290815p4348552.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
http://code.google.com/p/pharo/issues/detail?id=1802 Stef On Jan 13, 2010, at 9:53 AM, Alain Plantec wrote:
Lukas Renggli a écrit :
I suggest everybody to have a quick look at VW: - they have #copy and #postCopy as we do - they have #shallowCopy that is used from #copy as we do - they have #dcopy (what a horrible name) that is implemented in a similar way to what I suggested for #deepCopy
There is nothing else.
yes, I think we should adopt this with (dcopy -> deepCopy). Alain
Lukas
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
we should do something veryDeepFixupWith: deepCopier "If target and arguments fields were weakly copied, fix them here. If they were in the tree being copied, fix them up, otherwise point to the originals!!" veryDeepCopySibling "Do a complete tree copy using a dictionary. Substitute a clone of oldPlayer for the root. Normally, a Player or non systemDefined object would have a new class. We do not want one this time. An object in the tree twice, is only copied once. All references to the object in the copy of the tree will point to the new copy." veryDeepCopyUsing: copier "Do a complete tree copy using a dictionary. An object in the tree twice is only copied once. All references to the object in the copy of the tree will point to the new copy. Same as veryDeepCopy except copier (with dictionary) is supplied. ** do not delete this method, even if it has no callers **" | new refs newDep newModel | new := self veryDeepCopyWith: copier. copier references associationsDo: [:assoc | assoc value veryDeepFixupWith: copier]. "Fix dependents" refs := copier references. DependentsFields associationsDo: [:pair | pair value do: [:dep | (newDep := refs at: dep ifAbsent: [nil]) ifNotNil: [ newModel := refs at: pair key ifAbsent: [pair key]. newModel addDependent: newDep]]]. ^ new veryDeepCopyWith: deepCopier "Copy me and the entire tree of objects I point to. An object in the tree twice is copied once, and both references point to him. deepCopier holds a dictionary of objects we have seen. Some classes refuse to be copied. Some classes are picky about which fields get deep copied." | class index sub subAss new sup has mine | deepCopier references at: self ifPresent: [:newer | ^ newer]. "already did him" class := self class. class isMeta ifTrue: [^ self]. "a class" new := self clone. deepCopier references at: self put: new. "remember" (class isVariable and: [class isPointers]) ifTrue: [index := self basicSize. [index > 0] whileTrue: [sub := self basicAt: index. (subAss := deepCopier references associationAt: sub ifAbsent: [nil]) ifNil: [new basicAt: index put: (sub veryDeepCopyWith: deepCopier)] ifNotNil: [new basicAt: index put: subAss value]. index := index - 1]]. "Ask each superclass if it wants to share (weak copy) any inst vars" new veryDeepInner: deepCopier. "does super a lot" "other superclasses want all inst vars deep copied" sup := class. index := class instSize. [has := sup compiledMethodAt: #veryDeepInner: ifAbsent: [nil]. has := has ifNil: [ false ] ifNotNil: [ true ]. mine := sup instVarNames. has ifTrue: [index := index - mine size] "skip inst vars" ifFalse: [1 to: mine size do: [:xx | sub := self instVarAt: index. (subAss := deepCopier references associationAt: sub ifAbsent: [nil]) "use association, not value, so nil is an exceptional value" ifNil: [new instVarAt: index put: (sub veryDeepCopyWith: deepCopier)] ifNotNil: [new instVarAt: index put: subAss value]. index := index - 1]]. (sup := sup superclass) == nil] whileFalse. new rehash. "force Sets and Dictionaries to rehash" ^ new veryDeepInner: deepCopier "No special treatment for inst vars of my superclasses. Override when some need to be weakly copied. Object>>veryDeepCopyWith: will veryDeepCopy any inst var whose class does not actually define veryDeepInner:" On Jan 13, 2010, at 10:53 AM, Stéphane Ducasse wrote:
http://code.google.com/p/pharo/issues/detail?id=1802
Stef
On Jan 13, 2010, at 9:53 AM, Alain Plantec wrote:
Lukas Renggli a écrit :
I suggest everybody to have a quick look at VW: - they have #copy and #postCopy as we do - they have #shallowCopy that is used from #copy as we do - they have #dcopy (what a horrible name) that is implemented in a similar way to what I suggested for #deepCopy
There is nothing else.
yes, I think we should adopt this with (dcopy -> deepCopy). Alain
Lukas
_______________________________________________ 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
Now it would be nice to clean that because in VW you have copy, shallowCopy and postCopy and it works. They removed veryDeepCopy and other friends even when they were at the time were they could burn engineering time on that. So for me clone is one too many. And worse cloning and object cannot be a shallowCopy semantics. it should be more a veryDeepInnerVeryCopy (I could not resist sorry) Of course we already clean and remove the veryDeepInnerCopy.... No comment.
- #copy is the normal copy operation. It should be used by default and never overridden. It calls #postCopy that can be overridden to have class specific copy semantics.
- #shallowCopy does a shallow copy. It should never be overridden and only be used if you want to get these very specific semantics.
- #deepCopy does a deep copy. It should never be overridden and only be used if you want to get these very specific semantics.
- #clone comes from eToys and Morphic (AFAIK). It implements some other copy semantics than #copy. I don't think that anybody should call this method, other than code that depends on this particular copy behavior.
we should copy that in Object class comment and all the methods
where do you see that it is morphic related for me clone is only implemented on character, Boolean, Object, SMalltInt symbol, UndefinedObject
Back in the old days, Squeak 1.1 didn't have primitive 148 (which is now used by both #shallowCopy and #clone). #shallowCopy was the way to create a "one-level copy" of an Object. It had the same code as today, but with no primitive. Primitive 148 was introduced somewhere between 1.1 and 1.19 (note that 1.2 came after 1.19). 1.19 (and probably earlier versions, but not 1.1) had #clone which was primitive only and #shallowCopy which didn't use the primitive. Morphic was being ported to Squeak at the time and it was the only user of #clone. Morphs were copied by #clone which was pretty fast, while other objects used #shallowCopy. Later the use of #clone started to spread, until primitive 148 was added to #shallowCopy. Sends of #clone were replaced with #shallowCopy and #copy, but #clone was kept, probably for backwards compatibility.
#clone and #shallowCopy have a difference in their semantics. If the vm cannot allocate enough space for the new object, #clone raises an error immediately, while #shallowCopy signals the low space semaphore, so the image or the user can do something, then retries the copying.
Levente
This is exactly the same problematic as with #=. There can't be just one #=. Other clients might consider other things when comparing objects.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Now it would be nice to clean that because in VW you have copy, shallowCopy and postCopy and it works. They removed veryDeepCopy and other friends even when they were at the time were they could burn engineering time on that.
+10
So for me clone is one too many. And worse cloning and object cannot be a shallowCopy semantics. it should be more a veryDeepInnerVeryCopy (I could not resist sorry) Of course we already clean and remove the veryDeepInnerCopy.... No comment.
The strange thing about #shallowCopy is in SequenceableCollection. It overrides #shallowCopy and does not return a shallowCopy. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
2010/1/13 Lukas Renggli <renggli@gmail.com>:
Now it would be nice to clean that because in VW you have copy, shallowCopy and postCopy and it works. They removed veryDeepCopy and other friends even when they were at the time were they could burn engineering time on that.
+10
So for me clone is one too many. And worse cloning and object cannot be a shallowCopy semantics. it should be more a veryDeepInnerVeryCopy (I could not resist sorry) Of course we already clean and remove the veryDeepInnerCopy.... No comment.
The strange thing about #shallowCopy is in SequenceableCollection. It overrides #shallowCopy and does not return a shallowCopy.
Lukas
Yes, that sort of strange things forced me to introduce basicShallowCopy. This was a workaround but not a good fix. The good fix is in trunk : remove SequenceableCollection>>shallowCopy and define all the copy in term of postCopy and remove basicShallowCopy. Someone should just cherry pick in trunk. Nicolas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
this someone is busy :) On Jan 13, 2010, at 12:40 PM, Nicolas Cellier wrote:
2010/1/13 Lukas Renggli <renggli@gmail.com>:
Now it would be nice to clean that because in VW you have copy, shallowCopy and postCopy and it works. They removed veryDeepCopy and other friends even when they were at the time were they could burn engineering time on that.
+10
So for me clone is one too many. And worse cloning and object cannot be a shallowCopy semantics. it should be more a veryDeepInnerVeryCopy (I could not resist sorry) Of course we already clean and remove the veryDeepInnerCopy.... No comment.
The strange thing about #shallowCopy is in SequenceableCollection. It overrides #shallowCopy and does not return a shallowCopy.
Lukas
Yes, that sort of strange things forced me to introduce basicShallowCopy. This was a workaround but not a good fix. The good fix is in trunk : remove SequenceableCollection>>shallowCopy and define all the copy in term of postCopy and remove basicShallowCopy.
Someone should just cherry pick in trunk.
Nicolas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ 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
On Wed, 13 Jan 2010, Stéphane Ducasse wrote:
Now it would be nice to clean that because in VW you have copy, shallowCopy and postCopy and it works. They removed veryDeepCopy and other friends even when they were at the time were they could burn engineering time on that.
I'm sure there's a way to copy an object graph properly in VW (that's what #veryDeepCopy does).
So for me clone is one too many. And worse cloning and object cannot be a shallowCopy semantics. it should be more a veryDeepInnerVeryCopy (I could not resist sorry)
#clone is copying an object, not a graph. I think the name is coming from Self.
Of course we already clean and remove the veryDeepInnerCopy.... No comment.
What? Levente
- #copy is the normal copy operation. It should be used by default and never overridden. It calls #postCopy that can be overridden to have class specific copy semantics.
- #shallowCopy does a shallow copy. It should never be overridden and only be used if you want to get these very specific semantics.
- #deepCopy does a deep copy. It should never be overridden and only be used if you want to get these very specific semantics.
- #clone comes from eToys and Morphic (AFAIK). It implements some other copy semantics than #copy. I don't think that anybody should call this method, other than code that depends on this particular copy behavior.
we should copy that in Object class comment and all the methods
where do you see that it is morphic related for me clone is only implemented on character, Boolean, Object, SMalltInt symbol, UndefinedObject
Back in the old days, Squeak 1.1 didn't have primitive 148 (which is now used by both #shallowCopy and #clone). #shallowCopy was the way to create a "one-level copy" of an Object. It had the same code as today, but with no primitive. Primitive 148 was introduced somewhere between 1.1 and 1.19 (note that 1.2 came after 1.19). 1.19 (and probably earlier versions, but not 1.1) had #clone which was primitive only and #shallowCopy which didn't use the primitive. Morphic was being ported to Squeak at the time and it was the only user of #clone. Morphs were copied by #clone which was pretty fast, while other objects used #shallowCopy. Later the use of #clone started to spread, until primitive 148 was added to #shallowCopy. Sends of #clone were replaced with #shallowCopy and #copy, but #clone was kept, probably for backwards compatibility.
#clone and #shallowCopy have a difference in their semantics. If the vm cannot allocate enough space for the new object, #clone raises an error immediately, while #shallowCopy signals the low space semaphore, so the image or the user can do something, then retries the copying.
Levente
This is exactly the same problematic as with #=. There can't be just one #=. Other clients might consider other things when comparing objects.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ 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
_______________________________________________ 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
On Jan 13, 2010, at 9:14 AM, Levente Uzonyi wrote:
On Wed, 13 Jan 2010, Stéphane Ducasse wrote:
Now it would be nice to clean that because in VW you have copy, shallowCopy and postCopy and it works. They removed veryDeepCopy and other friends even when they were at the time were they could burn engineering time on that.
I'm sure there's a way to copy an object graph properly in VW (that's what #veryDeepCopy does).
not really so this is why I would like to keep veryDeepCopy
So for me clone is one too many. And worse cloning and object cannot be a shallowCopy semantics. it should be more a veryDeepInnerVeryCopy (I could not resist sorry)
#clone is copying an object, not a graph. I think the name is coming from Self.
Probably.
Of course we already clean and remove the veryDeepInnerCopy.... No comment.
What?
check squeak 3.8 or related.
Levente
- #copy is the normal copy operation. It should be used by default and never overridden. It calls #postCopy that can be overridden to have class specific copy semantics.
- #shallowCopy does a shallow copy. It should never be overridden and only be used if you want to get these very specific semantics.
- #deepCopy does a deep copy. It should never be overridden and only be used if you want to get these very specific semantics.
- #clone comes from eToys and Morphic (AFAIK). It implements some other copy semantics than #copy. I don't think that anybody should call this method, other than code that depends on this particular copy behavior.
we should copy that in Object class comment and all the methods
where do you see that it is morphic related for me clone is only implemented on character, Boolean, Object, SMalltInt symbol, UndefinedObject
Back in the old days, Squeak 1.1 didn't have primitive 148 (which is now used by both #shallowCopy and #clone). #shallowCopy was the way to create a "one-level copy" of an Object. It had the same code as today, but with no primitive. Primitive 148 was introduced somewhere between 1.1 and 1.19 (note that 1.2 came after 1.19). 1.19 (and probably earlier versions, but not 1.1) had #clone which was primitive only and #shallowCopy which didn't use the primitive. Morphic was being ported to Squeak at the time and it was the only user of #clone. Morphs were copied by #clone which was pretty fast, while other objects used #shallowCopy. Later the use of #clone started to spread, until primitive 148 was added to #shallowCopy. Sends of #clone were replaced with #shallowCopy and #copy, but #clone was kept, probably for backwards compatibility.
#clone and #shallowCopy have a difference in their semantics. If the vm cannot allocate enough space for the new object, #clone raises an error immediately, while #shallowCopy signals the low space semaphore, so the image or the user can do something, then retries the copying.
Levente
This is exactly the same problematic as with #=. There can't be just one #=. Other clients might consider other things when comparing objects.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ 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
_______________________________________________ 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
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, 13 Jan 2010, Stéphane Ducasse wrote:
On Jan 13, 2010, at 9:14 AM, Levente Uzonyi wrote:
On Wed, 13 Jan 2010, Stéphane Ducasse wrote:
Now it would be nice to clean that because in VW you have copy, shallowCopy and postCopy and it works. They removed veryDeepCopy and other friends even when they were at the time were they could burn engineering time on that.
I'm sure there's a way to copy an object graph properly in VW (that's what #veryDeepCopy does).
not really so this is why I would like to keep veryDeepCopy
So for me clone is one too many. And worse cloning and object cannot be a shallowCopy semantics. it should be more a veryDeepInnerVeryCopy (I could not resist sorry)
#clone is copying an object, not a graph. I think the name is coming from Self.
Probably.
Of course we already clean and remove the veryDeepInnerCopy.... No comment.
What?
check squeak 3.8 or related.
I see the same methods starting with veryDeep as in Pharo 1.1. Levente
Levente
- #copy is the normal copy operation. It should be used by default and never overridden. It calls #postCopy that can be overridden to have class specific copy semantics.
- #shallowCopy does a shallow copy. It should never be overridden and only be used if you want to get these very specific semantics.
- #deepCopy does a deep copy. It should never be overridden and only be used if you want to get these very specific semantics.
- #clone comes from eToys and Morphic (AFAIK). It implements some other copy semantics than #copy. I don't think that anybody should call this method, other than code that depends on this particular copy behavior.
we should copy that in Object class comment and all the methods
where do you see that it is morphic related for me clone is only implemented on character, Boolean, Object, SMalltInt symbol, UndefinedObject
Back in the old days, Squeak 1.1 didn't have primitive 148 (which is now used by both #shallowCopy and #clone). #shallowCopy was the way to create a "one-level copy" of an Object. It had the same code as today, but with no primitive. Primitive 148 was introduced somewhere between 1.1 and 1.19 (note that 1.2 came after 1.19). 1.19 (and probably earlier versions, but not 1.1) had #clone which was primitive only and #shallowCopy which didn't use the primitive. Morphic was being ported to Squeak at the time and it was the only user of #clone. Morphs were copied by #clone which was pretty fast, while other objects used #shallowCopy. Later the use of #clone started to spread, until primitive 148 was added to #shallowCopy. Sends of #clone were replaced with #shallowCopy and #copy, but #clone was kept, probably for backwards compatibility.
#clone and #shallowCopy have a difference in their semantics. If the vm cannot allocate enough space for the new object, #clone raises an error immediately, while #shallowCopy signals the low space semaphore, so the image or the user can do something, then retries the copying.
Levente
This is exactly the same problematic as with #=. There can't be just one #=. Other clients might consider other things when comparing objects.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ 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
_______________________________________________ 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
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
Argh yes you are right so we just removed one of them.... There was one which copy but not the dependents or I do know what So we will have to squash some of them.
check squeak 3.8 or related.
I see the same methods starting with veryDeep as in Pharo 1.1.
Levente
Levente
- #copy is the normal copy operation. It should be used by default and never overridden. It calls #postCopy that can be overridden to have class specific copy semantics.
- #shallowCopy does a shallow copy. It should never be overridden and only be used if you want to get these very specific semantics.
- #deepCopy does a deep copy. It should never be overridden and only be used if you want to get these very specific semantics.
- #clone comes from eToys and Morphic (AFAIK). It implements some other copy semantics than #copy. I don't think that anybody should call this method, other than code that depends on this particular copy behavior.
we should copy that in Object class comment and all the methods
where do you see that it is morphic related for me clone is only implemented on character, Boolean, Object, SMalltInt symbol, UndefinedObject
Back in the old days, Squeak 1.1 didn't have primitive 148 (which is now used by both #shallowCopy and #clone). #shallowCopy was the way to create a "one-level copy" of an Object. It had the same code as today, but with no primitive. Primitive 148 was introduced somewhere between 1.1 and 1.19 (note that 1.2 came after 1.19). 1.19 (and probably earlier versions, but not 1.1) had #clone which was primitive only and #shallowCopy which didn't use the primitive. Morphic was being ported to Squeak at the time and it was the only user of #clone. Morphs were copied by #clone which was pretty fast, while other objects used #shallowCopy. Later the use of #clone started to spread, until primitive 148 was added to #shallowCopy. Sends of #clone were replaced with #shallowCopy and #copy, but #clone was kept, probably for backwards compatibility.
#clone and #shallowCopy have a difference in their semantics. If the vm cannot allocate enough space for the new object, #clone raises an error immediately, while #shallowCopy signals the low space semaphore, so the image or the user can do something, then retries the copying.
Levente
This is exactly the same problematic as with #=. There can't be just one #=. Other clients might consider other things when comparing objects.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ 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
_______________________________________________ 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
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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Tue, Jan 12, 2010 at 11:55 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
Now it would be nice to clean that because in VW you have copy, shallowCopy and postCopy and it works. They removed veryDeepCopy and other friends even when they were at the time were they could burn engineering time on that.
I think you'll find VW has Object>>dcopy, which is essentially the same as veryDeepCopy, a structure-preserving graph copy. So VW has shallowCopy, copy built upon shallowCopy and postCopy, and dcopy. IMO all three are useful. Old deepCopy is not.
So for me clone is one too many. And worse cloning and object cannot be a shallowCopy semantics. it should be more a veryDeepInnerVeryCopy (I could not resist sorry) Of course we already clean and remove the veryDeepInnerCopy.... No comment.
- #copy is the normal copy operation. It should be used by default and never overridden. It calls #postCopy that can be overridden to have class specific copy semantics.
- #shallowCopy does a shallow copy. It should never be overridden and only be used if you want to get these very specific semantics.
- #deepCopy does a deep copy. It should never be overridden and only be used if you want to get these very specific semantics.
- #clone comes from eToys and Morphic (AFAIK). It implements some other copy semantics than #copy. I don't think that anybody should call this method, other than code that depends on this particular copy behavior.
we should copy that in Object class comment and all the methods
where do you see that it is morphic related for me clone is only implemented on character, Boolean, Object, SMalltInt symbol, UndefinedObject
Back in the old days, Squeak 1.1 didn't have primitive 148 (which is now used by both #shallowCopy and #clone). #shallowCopy was the way to create a "one-level copy" of an Object. It had the same code as today, but with no primitive. Primitive 148 was introduced somewhere between 1.1 and 1.19 (note that 1.2 came after 1.19). 1.19 (and probably earlier versions, but not 1.1) had #clone which was primitive only and #shallowCopy which didn't use the primitive. Morphic was being ported to Squeak at the time and it was the only user of #clone. Morphs were copied by #clone which was pretty fast, while other objects used #shallowCopy. Later the use of #clone started to spread, until primitive 148 was added to #shallowCopy. Sends of #clone were replaced with #shallowCopy and #copy, but #clone was kept, probably for backwards compatibility.
#clone and #shallowCopy have a difference in their semantics. If the vm cannot allocate enough space for the new object, #clone raises an error immediately, while #shallowCopy signals the low space semaphore, so the image or the user can do something, then retries the copying.
Levente
This is exactly the same problematic as with #=. There can't be just one #=. Other clients might consider other things when comparing objects.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ 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
_______________________________________________ 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
http://code.google.com/p/pharo/issues/detail?id=1790
basicShallowCopy was a workaround for some badly written copy in OrderedCollection. I did add it, then removed it in squeak/trunk. I suggest following the same path in Pharo.
participants (12)
-
Alain Plantec -
Alexandre Bergel -
Bouraqadi Noury -
Eliot Miranda -
Igor Stasenko -
Levente Uzonyi -
Lukas Renggli -
Martin McClure -
Nicolas Cellier -
Schwab,Wilhelm K -
Stan Shepherd -
Stéphane Ducasse