Taking a copy of an object

[Bruno Medeiros]

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