clone vs shallowCopy
Locked
123
123
 
|
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 > [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 |
|
|
2010/1/12 Levente Uzonyi <[hidden email]>:
> 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 >> [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 > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Noury Bouraqadi-2
2010/1/12 Bouraqadi Noury <[hidden email]>:
> 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 > [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 |
|
|
- #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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 > [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 |
|
|
In reply to this post by Igor Stasenko
> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Lukas Renggli
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 > [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 |
|
|
In reply to this post by Levente Uzonyi-2
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. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Nicolas Cellier
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. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
2010/1/12 Stéphane Ducasse <[hidden email]>:
> 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 > [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 |
|
|
In reply to this post by Stéphane Ducasse
> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 <[hidden email]>: >> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
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 |
|
|
In reply to this post by Nicolas Cellier
Nicolas Cellier wrote:
> 2010/1/12 Stéphane Ducasse <[hidden email]>: >> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Igor Stasenko
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 <[hidden email]>: >>> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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 |
|
|
2010/1/12 Stéphane Ducasse <[hidden email]>:
> > 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 <[hidden email]>: >>>> 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
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 > [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 |
|
|
In reply to this post by Stéphane Ducasse
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 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 >> [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 |
|
|
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 >>> [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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |