copy: self shallowCopy postCopy
Andreas Raab
andreas.raab at gmx.de
Tue Oct 18 21:47:37 UTC 2005
The problem with the "self shallowCopy postCopy" approach is that it
doesn't work. Say:
Object subclass: #TestClass
instanceVariableNames: 'a b'
...
TestClass>>postCopy
"Copy a and b"
a := a copy.
b := b copy.
If "a == b" before the copy then "a ~~ b" after the copy. In general,
without providing a context (like DeepCopier) it is impossible to treat
aliases correctly, so the copying you have here works only for the most
simplistic structures (pure trees with no aliases).
This gets even worse if you need to conditionally copy an object, say
because of copying a tree of morphs which contains an object that a leaf
(which knows nothing about whether the object it refers to is being
copied or not) refers to. When the leaf is actually copied the object it
refers to may be copied *afterwards* and the leaf needs to be aware of
that. The current mechanisms in Squeak, while complex, deal with all of
these cases correctly.
Cheers,
- Andreas
stéphane ducasse wrote:
> I was teaching today and showing to the students the difference of
> treatment between squeak and vw for managing copy.
>
> Squeak tries to have a smart generic way to copying objects and vw
> does the inverse delegate as much as possible to the objects which is
> much more oo and scalable (no deepInnerDeepDeepCopy).
>
> So I was thinking that it may be good to think if we want to introduce
> the same mechanism than in vw because it make a lot of sense to me.
>
> Object>>copy
> self shallowCopy postCopy
>
> Object>>postCopy
> ^ self
> Object>>shallowCopy
> <prim>
>
> then the classes can decide how they implement their own copy
> overriding postCopy
>
> So nice.
> I will have to study carefully the one of Squeak but I guess that vw
> had the
> same generic external approach and they realized it would not work in
> general
> since each class can be willing to have another copy semantics.
>
> Stef
>
>
More information about the Squeak-dev
mailing list
|