[Cuis] Copy vs Clone

H. Hirzel hannes.hirzel at gmail.com
Fri May 15 06:08:12 CDT 2015


I have summarized this thread so far under issue 55

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/55

NotesOnMorphic.md -- add note about #copy

Morphs should be copied using #copy.
 #clone should be deprecated.

Is this still the conclusion?

--Hannes

On 5/15/15, Ken.Dickey <Ken.Dickey at whidbey.com> 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.
>
> --
> -KenD
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




More information about the Cuis mailing list