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.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
3/08/2006 5:26:23 PM

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.
> 

a compiler generated .dup method would be nice.

Hasan Aljudy wrote:
> 
> a compiler generated .dup method would be nice.


Reflection and the ability to generate your own would be even better.

"Derek Parnell" <derek@nomail.afraid.org> wrote in message news:4war8mij9m44$.1xwxnpe32ro4e$.dlg@40tude.net...
> 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.

What's stopping you from using "dup" as the name?

#class Test {
#  Test dup() {
#    return new Test;
#  }
#}
#void main() {
#  Test t = new Test;
#  Test a = t.dup;
#}

L.

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();
> 

What's the "on" prefix for? I think the name should be something like:
dup()
Clone()
Copy()
and it should exist by default in the Object class, with a default implementation that does a shallow copy.

Also, it is redundant to specify a shallow copy function for each class: the code is the same for any class. It is something like:
  Object ShallowCopy(Object obj) {
    int len = obj.classinfo.init.length;
    auto data = (cast(ubyte*) obj)[0..len];
    return cast(Object) data.dup.ptr;
  }
So there should not be two different functions for each kind of copy, there should be only one, which conceptually is defined to do a deep copy.

> 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.
> 

Yes, I think that would be quite useful.

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

Tom S wrote:
> Hasan Aljudy wrote:
> 
>>
>> a compiler generated .dup method would be nice.
> 
> 
> 
> Reflection and the ability to generate your own would be even better.

well you already can create your own .dup
I mean it's just a method that returns typeof(this)

Bruno Medeiros wrote:
> Derek Parnell wrote:
> 
<Snip>
>> 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.
>>
> 
> Yes, I think that would be quite useful.
> 

Oh please, I hate the := operator, it's too ugly.

Hasan Aljudy wrote:
> 
> 
> Tom S wrote:
>> Hasan Aljudy wrote:
>>
>>>
>>> a compiler generated .dup method would be nice.
>>
>>
>>
>> Reflection and the ability to generate your own would be even better.
> 
> well you already can create your own .dup
> I mean it's just a method that returns typeof(this)

There was a subtle difference in what I wrote :) 'generate' vs 'create'  - that is. Generating own .dup and/or serialization functions based on meta data is different than writing/creating your own routines to handle that by hand.


--
Tomasz Stachowiak

Tom S wrote:
> Hasan Aljudy wrote:
> 
>>
>>
>> Tom S wrote:
>>
>>> Hasan Aljudy wrote:
>>>
>>>>
>>>> a compiler generated .dup method would be nice.
>>>
>>>
>>>
>>>
>>> Reflection and the ability to generate your own would be even better.
>>
>>
>> well you already can create your own .dup
>> I mean it's just a method that returns typeof(this)
> 
> 
> There was a subtle difference in what I wrote :) 'generate' vs 'create'  - that is. Generating own .dup and/or serialization functions based on meta data is different than writing/creating your own routines to handle that by hand.
> 
> 
> -- 
> Tomasz Stachowiak

Sorry, what's the difference of writing code and "generating code by yourself"?

On Thu, 03 Aug 2006 14:26:08 +0100, Bruno Medeiros wrote:

> 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();
>> 
> 
> What's the "on" prefix for? I think the name should be something like:

The 'on' prefix is a *hint* to Walter that I'd really like this function to be invoked via a new operator and not necessariliy called directly.

> dup()
> Clone()
> Copy()
> and it should exist by default in the Object class, with a default
> implementation that does a shallow copy.

Yes, a default shallow copy defined in Object would be a good idea. In that case an operator would not be needed for shallow copying.

> Also, it is redundant to specify a shallow copy function for each class:
> the code is the same for any class. It is something like:
>    Object ShallowCopy(Object obj) {
>      int len = obj.classinfo.init.length;
>      auto data = (cast(ubyte*) obj)[0..len];
>      return cast(Object) data.dup.ptr;
>    }
> So there should not be two different functions for each kind of copy,
> there should be only one, which conceptually is defined to do a deep copy.

Not sure I agree here. The shallow copy coulod be generic as you demonstrated, but a deep copy is very Object-specific and would need to be defined in the class that needed it.


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