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.


Yes; although "we", as a group, /could/ commandeer the opDup() and opClone() method-names ourselves ~ it's surprising how having the op-prefix can persuade people to comply with a convention, especially when there's some potential that the compiler may catch up later :)

If we did start using these names, how might it conflict? Would opDup potentially mean something different in the future? Or opClone? What doth Walter say?

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 "::=" ?

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?

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.

On Thu, 10 Aug 2006 16:36:04 +1000, Derek Parnell wrote:
>
> 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.

The problem is that a new operator doesn't really solve anything.  There is no way for the compiler to strictly enforce that 'opClone' performs a clone, much as it can not check that 'opAdd' performs an addition.  Adding new operators is hardly a guarantee that programmers will use them sensibly, and it seems unnecessary given the current property syntax is equivalent.

A convention might seem a bit weak, but it has worked successfully in the past.  Consider C++'s copy constructor and operator= ; neither have any guarantee that they will act as intended.  It is the responsibility of the programmer alone to ensure they are correct.  However, it is not very difficult to correctly implement and verify these sorts of methods, it should not create much of a burden.

Derek Parnell wrote:
> 
> And maybe one day (hoping against precedent) that Walter will actually see
> that an operator for copying stuff is not such a stupid idea.
> 
>    auto backup := q; // invokes q.onCopy() if it exists.
> 

What's the sense of having a binary operator for an unary operation? Clearly it would have to be unary like ":foo" suggested elsewhere or "@foo" or whatever.

But would it be worth it? I don't think so, I think the gain in syntactic sugar is not worth adding an operator for this function. More on that, is commented after the Hasan's - Derek's exchange below.

For me, the operator := would be useful, but as a proper copy operator, a binary operator, which would copy the contents of the right side operand to the left side one. The difference from the proposed:
  auto backup := q; // invokes q.onCopy() if it exists.
is that the  identity of backup is changed as it is assigned to a new object. Under the binary version, the actual contents of the left-side instance ("backup" in that example) are changed.
This would allow, among other things, to work with reference types as if they were value types, which I think would be useful in many scenarios. Like, for example, in a code that uses struct variables and struct copying, changing the struct vars types from struct values to struct pointers. Or changing the type of a var from int, to BigNum, a hypothetical integer class of unlimited precision.
Another use case is to be able to copy structs whose *abstract-state* is more than just the "shallow" value copied by a shallow copy. That is, if you have structs that have references to data that are part of the struct's abstract-state, then merely copying the struct value (using the assign operator) won't work, as the assign operator does a shallow copy in structs, which won't result in a correct(complete) copy.
Also, a copy operator would supersede the current awkward and "special-case" syntax of Array Copying and Array Setting:
  int[3] s;
  int[3] t;
  s[] = t;	// the 3 elements of t[3] are copied into s[3]
  s[] = t[];	// the 3 elements of t[3] are copied into s[3]

  int[3] s;
  int* p;
  s[] = 3;		// same as s[0] = 3, s[1] = 3, s[2] = 3
  p[0..2] = 3;		// same as p[0] = 3, p[1] = 3

Instead, those would become respectively:
  s := t;
  s := t;

  s := 3;
  p[0..2] := 3;


Derek wrote:
> On Thu, 03 Aug 2006 17:12:39 -0600, Hasan Aljudy wrote:
>
>> why an operator?
>> a method/property is more suitable, I think.
>
> Where does this train of thought stop? Why an operator for anything? Do we
> need '=' '>=' '+=' etc... when we have all those useful opXXX functions
> handy? Of course we do, because it makes coding easier to read and write.
>
> The action of cloning an item is quite a common action and having to use a


"Where does this train of thought stop? Why an operator for anything? "

I can turn that question around, why not an operator for other operations like new or delete? Wouldn't it make coding easier to read and write?:
  auto foo = #Foo();  // new Foo()
  @foo;   // delete foo
*shivers*...

So we can't have a sweeping, generalizing idea stating if it's worth or not to have an operator, or else we would have D as APL (operator abuse) or SmallTalk (almost no operators). Each case has to be considered to see if it's worth it. For dup I don't think it is:

For starters, some of the advantages of having operators are the ease of use from being able to use infix notation and predefined operator precedence, which is only relevant for binary ops and not dup.
Second, from looking at dup's frequency of use (often but not that often), complexity of it's operation (more complex operations should be more verbose IMO), and gain in syntactic sugar (minimal, both in typed characters as well as form).
And I don't see any other advantages in having a dup operator. (note the next comment)

> method name is not as convenient as an operator. Also, an operator can act
> with objects, structs, arrays, and basic-types where as method names don't
> work so well with all types. This simplifies template construction.
>

I don't see the problem here, a templated free function should work as well for any kind of type (like the incomplete one I mentioned elsewhere). (If a method can and/or should be used instead of a free function, well that's another problem altogether.)


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

> Derek Parnell wrote:

... a whole lot of wasted bandwith that is never going to happen anyway so who gives a damn about arguing over the details.

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"

Those of you who participated / care about this discussion on copying:

I created a skeletal page for consolidating the arguments made in this thread:
http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList/CopyOperator

Please feel free to flesh it out a bit more.

--bb

Derek Parnell wrote:
> Currently there doesn't seem to be any standard D mechanism (read:
> operator) to take a copy of an object. So are there any suggestions for a
> name that we can all agree on; one that might become an unofficial
> standard? 
> 
> For arrays we have the 'dup' property but for objects there is nothing that
> the compiler assumes. I'm partial to 'onDup' or 'onCopy', and maybe even a
> 'onDeepCopy' as an additional function.
> 
> Example:
> 
>   class Foo
>   {
>       int x;
>       Bar b;
> 
>       this(int y)       {
>            x = y;
>            b = new Bar(y);
>       }
> 
>       Foo onCopy()
>       {
>           Foo t;
>           t = new Foo(x);
>           return t;
>        }
>    }
> 
>    . . . 
> 
>    auto backup = q.onCopy();
> 
> And maybe one day (hoping against precedent) that Walter will actually see
> that an operator for copying stuff is not such a stupid idea.
> 
>    auto backup := q; // invokes q.onCopy() if it exists.
>