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