clone vs shallowCopy
Locked
123
123
 
|
> #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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Levente Uzonyi-2
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 >>> [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 _______________________________________________ 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
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: [hidden email] [mailto:[hidden email]] On Behalf Of Lukas Renggli Sent: Wednesday, January 13, 2010 2:54 AM To: [hidden email] 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 [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
> 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 _______________________________________________ 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
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 > [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 Lukas Renggli
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 > [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 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 >>>> [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 > > > _______________________________________________ > 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 |
|
|
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 >>>>> [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 >> >> >> _______________________________________________ >> 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 |
|
|
In reply to this post by Levente Uzonyi-2
>> 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 _______________________________________________ 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 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. 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 >>>>>> [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 >>> >>> >>> _______________________________________________ >>> 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 > 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 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 > [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 |
|
|
>> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Levente Uzonyi-2
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 >>>>>>> [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 >>>> >>>> >>>> _______________________________________________ >>>> 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 > _______________________________________________ > 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 Alain Plantec-4
+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 > [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 Alain Plantec-4
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 > [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 Alain Plantec-4
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 > [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 |
|
|
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 >> [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 |
|
|
In reply to this post by Lukas Renggli
2010/1/13 Lukas Renggli <[hidden email]>:
>> 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 > [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 |
|
|
this someone is busy :)
On Jan 13, 2010, at 12:40 PM, Nicolas Cellier wrote: > 2010/1/13 Lukas Renggli <[hidden email]>: >>> 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 >> [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 |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |