On 18 oct. 05, at 23:47, Andreas Raab wrote:

> 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).

Yes but is it not the responsibility of TestClass to know that a ==  
b. Because this is a kind of invariant of the class.


> 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.

Ok I will read it then.

Stef

>
> 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
>>
>
>
>