Forwarding to squeak-dev for consideration after the next release.
Object>>clone can be replaced by #shallowCopy. Perhaps it is time to
deprecate #clone.
Juan is removing it from Cuis, with reference to this summary by Levente:
http://lists.gforge.inria.fr/pipermail/pharo-project/2010-January/019801.htmlDave
On Thu, May 14, 2015 at 10:53:12AM -0300, Juan Vuletich wrote:
> On 5/14/2015 12:22 AM, David T. Lewis wrote:
> >On Wed, May 13, 2015 at 11:24:09PM -0300, Juan Vuletich wrote:
> >>Does anybody know why #clone was added to Squeak?
> >>
> >I do not know the historical background, but Object>>clone invokes #primitiveClone
> >in the VM. This is an efficient shallow copy, in which the object header and data
> >fields are copied to a newly allocated object, and the object hash and GC bits
> >are updated in the new copy.
> >
> >I think that this must have been done for efficiency, to provide the fastest
> >possible means of shallow copying an object. The methods in the VM and in Object
> >are both old enough that they had no author initials, so this was a very early
> >optimization in Squeak.
> >
> >Dave
>
> Thanks Dave.
>
> I searched a bit more and found
>
http://lists.squeakfoundation.org/pipermail/vm-dev/2014-February/014683.html
> and the more detailed
>
http://lists.gforge.inria.fr/pipermail/pharo-project/2010-January/019801.html
> (by Levente).
>
> After these references, I decided to remove #clone from Cuis. Most
> senders were replaced by sends to #shallowCopy (it uses the same VM
> primitive). But for several, calling #copy works the same, and #copy
> sounds more natural to me. I also refactored several implementations of
> #copy et al, in SequenceableCollection and AbstractSound hierarchies.
> Will commit to github soon.
>
> Cheers,
> Juan Vuletich
Locked
