Taking a copy of an object

[kris]

Bruno Medeiros wrote:
> 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.


Speak for yourself, Bruno: all of this is simply taken for granted in 
some of the other posts.


> 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.
>