[Cuis] Copy vs Clone

[Juan Vuletich]

Hi Ken,

On 5/15/2015 7:33 AM, Ken.Dickey wrote:
> I seem to recall an early Smalltalk paper (OOPSLA?) on "Creation Relations" which specifically manage share vs duplicate copy semantics.
>
> I am most familiar with this from prototype based multimedia authoring environments.
>
> In brief, there are cases where one wants to distinguish where ivar state is shared vs individual.
>
> So I make a new, say automobile.  It gets its own (unshared) tires, doors, and engine but all cars manufactured by Honda share their manufacturer.
>
> I believe this is the reason for Object's definition of #copy, which allows complete control of share/duplicate:
>
> Object>>copy
> 	^self shallowCopy postCopy
>
> I am not proposing a system which manages "creation relations" here, just pointing out the need for awareness of the Share vs Duplicate aspect of Copy/Clone semantics.
>
> Since I am working on adding drag-n-drop behaviors to individual morphs, my usages are more prototype like.  More Self-like.
>
> Morph's #copy has very different semantics which basically disallows sharing:
>
> Morph>>copy
> 	^ Object unStream: (ReferenceStream streamedRepresentationOf: self)
>
> Hence some of my inital confusion with #copy.  Same name, different semantics.
>

  Well, but Morph is the same as your automobile. Copying a morph 
(usually) means copying submorphs. But not owner (otherwise, the whole 
World gets copied). This is taken care at Morph >> storeDataOn: I know 
this is rather hidden, code is not really clear, and maybe some 
framework to handle "creation relations" would be in order.

The shallowCopy postCopy approach works only for objects that don't form 
graphs. For these, the issues of duplications appears. The old 
#veryDeepCopy from ST-80 was complicated, and it had problems. I claim:

1) appropriate semantics for copying is usually a matter for each object 
to define. That's why it is ok to copy the #copy method from Object to 
your morph if appropriate.

2) The problems of duplication, identity, etc, are the same for copy as 
for serialization. That's why it is ok to use a serializer to copy graph 
objects.

So, I recommend (as general advice) to use clean closures if at all 
possible (as I said in the other thread), and to use the serializer to 
copy objects that form graph structures (like morphs). But, as #copy 
semantics is a responsibility for each object to provide, if this 
general advice is not applicable, instead of calling #shallowCopy, or 
creating new copy messages, I recommend implementing #copy appropriately 
for each class.

I hope all this makes sense for you.

Cheers,
Juan Vuletich