[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