hummm... I wonder if this is already available and i just didn't see what's the correct syntax to do it, or if it is just plain missing.

since all object are held by reference, there might be some times when you want to copy them. And if the object it self holds references to other object, in depth copy could be usefull. While there is no special difficulty to do it case by case, it seems to me there is no general way to do it. As i see it, the following stuff would be usefull:

* a "Object clone()" method in the Object class.
* a .clone property on arrays, behaving like this :
- indentical to .dup for arrays of basic types
- call .clone on all elements for array of array
- call clone() on all elements for arrays of objects

So is it there already under a different form?
if not, is there a good reason why it is not there?

walter does not like shallow copies, and thus "deep" copies are built into the language :)

class A
{
 int x;
}

void main()
{
 A a=new A;
 A b=a;
 printf("%x\n%x\n",&a,&b);
}

this prints the addressess of a and b.  clearly they are different, but b now has the same *data* as a.  i love this feature :)

Florian RIVOAL wrote:

>hummm... I wonder if this is already available and i just didn't see what's the
>correct syntax to do it, or if it is just plain missing.
>
>since all object are held by reference, there might be some times when you want
>to copy them. And if the object it self holds references to other object, in
>depth copy could be usefull. While there is no special difficulty to do it case
>by case, it seems to me there is no general way to do it. As i see it, the
>following stuff would be usefull:
>
>* a "Object clone()" method in the Object class.
>* a .clone property on arrays, behaving like this :
>- indentical to .dup for arrays of basic types
>- call .clone on all elements for array of array
>- call clone() on all elements for arrays of objects
>
>So is it there already under a different form?
>if not, is there a good reason why it is not there?
>
>
>  
>

I brought this up before.  I think it should be done by some standard interfaces (or abstract classes -> which allow auto-up-casting).  For automatic support, things would be easier when property RTTI comes in to D (fingers crossed for 2.0).

-- 
-Anderson: http://badmama.com.au/~anderson/

Jarrett Billingsley wrote:

>walter does not like shallow copies, and thus "deep" copies are built into
>the language :)
>
>class A
>{
> int x;
>}
>
>void main()
>{
> A a=new A;
> A b=a;
> printf("%x\n%x\n",&a,&b);
>}
>
>this prints the addressess of a and b.  clearly they are different, but b
>now has the same *data* as a.  i love this feature :)
>
>  
>
I'm tempted to say - what the hell are you on about - but I won't.  That is not a deep copy, that is a reference (or pointer) copy.  D does not support shallow or deep copies for classes, although it does support shallow copies for structs.  Take a gaze at this:

class A
{
   int x;
}

void main()
{
   A a=new A;
   a.x = 10;
   A b=a;
   b.x = 11;
   printf("%d\n%d\n",a.x,b.x);  //What is the result?
}

-- 
-Anderson: http://badmama.com.au/~anderson/

> I'm tempted to say - what the hell are you on about

go ahead, say it :(

i forgot about that hidden level of abstraction in there.  thus the pointers are different but each point to the same thing.

Florian RIVOAL wrote:

<snip>
> since all object are held by reference, there might be some times when you want
> to copy them. And if the object it self holds references to other object, in
> depth copy could be usefull.

For certain applications, such as duplicating a tree structure where there's a reason to do so.  But I'm not sure that it's useful enough in general.

> While there is no special difficulty to do it case
> by case, it seems to me there is no general way to do it. As i see it, the
> following stuff would be usefull:
> 
> * a "Object clone()" method in the Object class.
> * a .clone property on arrays, behaving like this :
> - indentical to .dup for arrays of basic types
> - call .clone on all elements for array of array
> - call clone() on all elements for arrays of objects
> 
> So is it there already under a different form?
> if not, is there a good reason why it is not there?

What would Object.clone do?

(a) a memberwise shallow copy?
(b) a memberwise deep copy, at the risk of running into a circular structure and taking up infinite time and memory?
(c) just return this, enabling the class designer to override it to actually copy?

If we chose (a) or (b), then class designers would need to override it if cloning the class makes no sense.  This goes against the principle that subclasses are supposed to extend functionality, not remove it. This leaves (c), a safe default behaviour, which also enables arrays of objects to be cloned as deeply as allowed by the classes involved.  But it also brings us back to the issue of the class designer forgetting to add new fields to the clone method, unless we give some kind of controlled access to built-in 'memberwise shallow copy' and 'memberwise clone' statements.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

In article <cd168g$v4b$1@digitaldaemon.com>, Stewart Gordon says...
>What would Object.clone do?
>
>(a) a memberwise shallow copy?
>(b) a memberwise deep copy, at the risk of running into a circular
>structure and taking up infinite time and memory?
>(c) just return this, enabling the class designer to override it to
>actually copy?

Here's my $0.02. :)

There are plenty of reasons why you don't want to have a platform/language default to a deep copy for structs and classes.  Circular structures (as you mentioned above) are just one example.  Classes that aren't threadsafe, and protect fields via method access are another.  You might not want to duplicate exceptionally deep trees and other huge data structures due to memory/cache issues.

Arcane Jill has also mentioned in this NG the implications of not having explicit memory control when writing very-secure applications.  Not being able to guard any member against a deep .clone() operation would be disasterous to such applications IMO.

The best compromise would be something like (C): to have Object.clone default to
a shallow copy, much like .dup() does for arrays. Actually, .dup() should
probably be used for objects too for language consistency.  If need be,
clone()/.dup() can then be overridden to return anything the implementor wants:
this, null, an uninitalized struct/class, or even throw an exception if the
operation is not allowed.

- Pragma

In article <cd185b$12lr$1@digitaldaemon.com>, pragma <EricAnderton at yahoo dot com> says...
>
>In article <cd168g$v4b$1@digitaldaemon.com>, Stewart Gordon says...
>>What would Object.clone do?
>>
>>(a) a memberwise shallow copy?
>>(b) a memberwise deep copy, at the risk of running into a circular
>>structure and taking up infinite time and memory?
>>(c) just return this, enabling the class designer to override it to
>>actually copy?
>
>Here's my $0.02. :)
>
>There are plenty of reasons why you don't want to have a platform/language default to a deep copy for structs and classes.  Circular structures (as you mentioned above) are just one example.  Classes that aren't threadsafe, and protect fields via method access are another.  You might not want to duplicate exceptionally deep trees and other huge data structures due to memory/cache issues.
>
>Arcane Jill has also mentioned in this NG the implications of not having explicit memory control when writing very-secure applications.  Not being able to guard any member against a deep .clone() operation would be disasterous to such applications IMO.
>
>The best compromise would be something like (C): to have Object.clone default to
>a shallow copy, much like .dup() does for arrays. Actually, .dup() should
>probably be used for objects too for language consistency.  If need be,
>clone()/.dup() can then be overridden to return anything the implementor wants:
>this, null, an uninitalized struct/class, or even throw an exception if the
>operation is not allowed.
>
>- Pragma
>
>
>

pragma <EricAnderton at yahoo dot com> wrote:
<snip>
> The best compromise would be something like (C): to have Object.clone default to a shallow copy, much like .dup() does for arrays.  Actually, .dup() should probably be used for objects too for language consistency.

Actually, we should be careful to distinguish between .dup (a shallow copy, by definition) and .clone (a deep copy, or as deep as allowed). But yes, clone would _default_ to a shallow copy at the most.

If we're going to have shallow object copies as a default behaviour, then we might as well define it in Object.dup, and have Object.clone simply call this method.  We'd need clear documentation of the contractual difference between them.

> If need be, clone()/.dup() can then be overridden to return anything the implementor wants: this, null, an uninitalized struct/class, or even throw an exception if the operation is not allowed.

I don't see any point in making this a disallowed operation.  If copying the object doesn't make sense for whatever class, we might as well copy the reference instead.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

>> If need be, clone()/.dup() can then be overridden to return anything the implementor wants: this, null, an uninitalized struct/class, or even throw an exception if the operation is not allowed.
>
>I don't see any point in making this a disallowed operation.  If copying the object doesn't make sense for whatever class, we might as well copy the reference instead.

Not sure either, but ask the guys at working for sun, they might have an idea, since java includes this behaviour : it throws an exception if you try to clone something without explicit mention it is clonable.