Taking a copy of an object

[Dave]

kris wrote:
> 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?
> 

I would agree - it'd be important for templates also.