Taking a copy of an object

[kris]

kris wrote:
> Derek Parnell wrote:
> 
>> On Thu, 10 Aug 2006 00:30:15 -0400, Mikola Lysenko wrote:
>>
>>
>>> Adding a virtual deep copy method to Object is a bad idea.
>>
>>
>>
>> ...
>>
>>
>>> A different solution is to require each type to explicitly state if 
>>> it supports deep-copies at compile time.
>>
>>
>> ...
>>  
>>
>>> If everyone adheres to this convention, the following templates to allow
>>> anyone to test if a type is clonable at compile time - and easily 
>>> perform
>>> a clone.  
>>
>>
>>
>> ...
>>
>>
>>> For completeness, there is also a shallow copy or 'dup'
>>> operation using the same technique.
>>
>>
>>
>> Yes. This is most of what I was trying to get across.
>> The only problem is the phrase "If everyone adheres to this convention".
>> That will never happen, people being as they are. This is why I'd like
>> these capabilities to be supported by the compiler via the use of 
>> operators
>> that invoke the associated 'op' function.
> 
> 
> Somewhat tongue-in-cheek: I guess if the dup operator were to become 
> ":=" then clone would be "::=" ?

Perhaps better to use properties instead of operators? Thus, x.dup; 
would invoke the opDup() method where appropriate (and error if not 
supported), and x.clone; would invoke opClone()?

At least that would be compatible with current .dup conventions, and 
avoid introducing disputable symbolic operators? Otherwise, we might end 
up with smiley's as operators :)

It wouldn't be entirely necessary, but perhaps clone, like dup, might be 
supported for native-types directly (int, char*[], etc)? For the sake of 
consistency?