Taking a copy of an object

[Derek Parnell]

On Thu, 03 Aug 2006 23:19:23 -0700, Kirk McDonald wrote:

> opDup appeals to me

Me too <g>

> , but more consistent would probably be a standard 
> .dup property. Despite what others have said, := is not a terrible 
> operator. 

Agreed, but I'm not really fussed.

> However, having := be overloaded with a "dup" function instead 
> of an "opDup" function is inconsistent with the other operator overloads.

Yes. Let's stick with consistency.
 
> So let's get the problem clear before we go proposing solutions: We want 
> a standard way of getting a copy of an object. 

Rather than using the term 'object' here, let's use the term 'item' because
it is not so ambiguous. In this way, 'item' can mean every data type
supported by D.

> We can either use an 
> operator for this purpose (such as :=), or a standard method (such as 
> .dup, as arrays currently use for the same purpose).
> 
> The := operator should work for classes, structs, arrays, and other 
> primitive types. Arrays already have the .dup property, so := can use 
> that. Remember that structs use value semantics. Assigning a struct the 
> normal way copies its members. So, for structs and the various primitive 
> types (that is to say, all of the types that use value semantics), := 
> will be identical to a regular assignment.

Hmmm... not so certain about that. A shallow copy (bit-by-bit) is already
performed by .dup and struct assignment, but we need a neat way to express
that we want a deep copy done. That is, we want the information copied and
not just the bits in the source item. Such that if an item contains
references (dynamic arrays, objects, and other pointers) it might want to
take copies of all their contents too. 

  char[][] theFile;
  char[][] backup;
  . . .
  backup := theFile;  // Make a copy of all the strings, not just
                      // the references to the strings.

  class Foo
  {
      Bar b;
  }

  Foo a := aFoo;  // Takes a copy of the Foo object *and* the 
                  // contained Bar object, not just a copy of
                  // the reference to the Bar object.


> I suggest a copy constructor as a way of overloading := for class 
> objects. This is a C++ thing, but it is actually a fairly elegant 
> solution, I think.

Whatever. I'm not fussed how its done so long as it makes writing and
reading code easier to do.
 
> The complication, now, is getting a constant way of getting a copy of 
> some object or value when we don't actually want to assign it to 
> anything (say, in a function call). My initial thought is to use unary : 
> to mean "copy-of" (this is consistent with the := operator), but (not 
> knowing much about how the parser works), I can't help but think that 
> this might interfere with labels or the trinary ?: operator or 
> something. Someone care to comment on that? The syntax looks fine:
> 
> fn( i, j, :obj); // send a copy of obj to the function

How about ...

    fn(i, j, auto := obj); //??? 

as the keyword 'auto' already implies a temporary object that is
automatically destroyed when end of scope is reached.

> So, for both the proposed := copy-assignment operator and unary : copy 
> operator, the various copying mechanisms would be:
> 
> class instances:                copy constructor

Ok, whatever.

> arrays/AAs:                     dup property

Nah ... needs a 'copy constructor' too, I think.

> structs, 
Nah ... needs a 'copy constructor' too, I think.

> primitive types, etc:  by-value copy

Ok.

> We wouldn't even have to provide a copy constructor in Object, you know. 
> Trying to use these operators on an instance of a class that doesn't 
> define a copy constructor would just be a compiler error, like any other 
> undefined operator overload or method you try to use.

Yeah, doesn't matter that much to me either way.
 
> Thoughts?

hmmm...chocolate-iced donut and hot coffee, but that's not relevant I
guess. <g>

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
4/08/2006 4:29:20 PM