Taking a copy of an object
Bruno Medeiros
brunodomedeirosATgmail at SPAM.com
Tue Aug 8 08:00:26 PDT 2006
Derek wrote:
> On Thu, 03 Aug 2006 14:12:03 -0600, Hasan Aljudy wrote:
>
>
> Please, feel free to suggest other things that might be suitable for a
> deep-copy operator. One that would be usable on all data types and meants
> that the information in the left-hand-side thingy would be copied and the
> right-hand thingy would 'hold' that copy.
>
> For objects, it would invoke onDup/onCopy/onClone/onDeepCopy/onWhatever
> (the name doesn't matter) if it existed, otherwise its a compile time
> error. The function would return the same datatype as the object that owns
> the function, meaning that Foo.onDup can't return a Bar or its parent type
> or an interface - it must return a Foo object instance.
>
> For arrays it is identical to the .dup property.
>
> For basic datatypes it is identical to moving the bit value from one to
> another variable (no conversion or transformations allowed).
>
> Therefore the lefthand side and righthand side thingy must be the same
> datatype.
>
I've just realized a little nuance that both I and the rest of us are
tripping on: There are two similar but distinct notions of a copy
operation, not just one.
The first one, usually called duping or cloning, is creating a new
instance which is a copy of an existing item/data-instance (a one
operand operation).
The second one, is copying one item to another existing one (a two
operand operation), which is more general than the former.
Note the difference between the terms "create a copy" and simply "copy".
We've been mixing these two concepts a bit, but they should be clearly
separate. It won't work well to try to have one do the job of the other,
rather we can have both in the language:
foo.opCopy(bar) // copies bar into foo;
foo := bar // same as above
foo.Clone() // creates a (deep) copy of foo
note that Clone is the same (conceptually at least) as:
(new typeof(foo)).opCopy(foo);
or even:
foo.dup.opCopy(foo);
if .dup does a shallow copy.
One could also think of a two-operand shallow-copy operation, but that
seems like going too far, I don't believe that would be useful.
In fact, I'm also not that sure if it is much useful for a datatype that
already has a deep self-copy function to have shallow self-copy too.
Derek mention the example of arrays, but even so...
Clone should be a virtual method in the Object hierarchy. As for opCopy,
I'm not sure. If it is a final method, you're limited in what you can do
with polymorphism. If it is virtual method, then the method has to have
a parameter of type Object, and so one has to write some dynamic
dispatch code in the method to handle the proper runtime types.
The names could be other of course, but my suggestion is as per the
examples above: self-copy is called "Clone" or "dup", and two-operand
copy is "Copy" or "opCopy". The names "dup" and "Clone" are likely
inappropriate for a Copy operation.
Additionally, we could maybe also call "Clone" to the *deep* copying,
and "dup" to *shallow* copying, if there is a need to have both.
--
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
More information about the Digitalmars-d
mailing list