deep/shallow copy - constructor v Object.copy()

[VisionSet]

Is there any kind of convention that dictates where it is usual to perform
shallow and deep copies?
I prefer to use copy constructors to implement any kind of copy, but now I
find the need for a shallow and deep copy in the same class.
I haven't ever needed to implement copy(), I imagine that its purpose is for
RTTI.

 

[VisionSet]

Is there any kind of convention that dictates where it is usual to perform
shallow and deep copies?
I prefer to use copy constructors to implement any kind of copy, but now I
find the need for a shallow and deep copy in the same class.
I haven't ever needed to implement copy(), I imagine that its purpose is for
RTTI.

And where I said copy() of course I meant clone().

 

[Karthik]

Is there any kind of convention that dictates where it is usual to perform
shallow and deep copies?
I prefer to use copy constructors to implement any kind of copy, but now I
find the need for a shallow and deep copy in the same class.

Can you elaborate on this a little bit. When you say, you want both
shallow and deep copy, you would want to revisit that.
Most of the cases, people override the function only because they
want a deep copy.
If there is still a valid reason, why there ought to be two copies, I
would suggest that - you write a method, something like this.

public Object shallowCopy( Object o ) {
..........
}

But think twice if you really need something like that ( that would
affect the 'readability' of the code for sure ).

 

[Roedy Green]

I prefer to use copy constructors to implement any kind of copy, but now I
find the need for a shallow and deep copy in the same class.
I haven't ever needed to implement copy(), I imagine that its purpose is for
RTTI.

there is also clone.

 

[John C. Bollinger]

Is there any kind of convention that dictates where it is usual to perform
shallow and deep copies?

I'd say you perform deep copies only where necessary, and shallow copies
everywhere else. The trick is to determine the meaning of "necessary"
for your application, and that may not be straightforward.

I prefer to use copy constructors to implement any kind of copy, but now I
find the need for a shallow and deep copy in the same class.

That may well be, but I am inclined to suspect that the need could be
removed by a round of refactoring. I would be nervous at the prospect
of putting both behaviors on the same class because there is then great
opportunity for users to accidentally confuse them.

I haven't ever needed to implement copy(), I imagine that its purpose is for
RTTI.

You mean "clone()", you wrote elsewhere. In that context then, do you
mean you think the purpose is to _avoid_ the need for RTTI? In that I
would partially agree with you -- only partially, because you still have
to worry about whether the objects in question are Cloneable. Also, if
you plan for such a feature in your own classes then you can usually
implement it in a polymorphic way without using clone.


John Bollinger
(e-mail address removed)

 

[Roedy Green]

I'd say you perform deep copies only where necessary, and shallow copies
everywhere else. The trick is to determine the meaning of "necessary"
for your application, and that may not be straightforward.

If your objects are immutable that you reference, then shallow copy
will suffice. You may find it easier to create new immutable objects
as needed than to deal with deep copies.

Deep copies are a bit like pulling on a thread on a sweater. It can
just keep going and going unexpectedly far.

 

[John C. Bollinger]

If your objects are immutable that you reference, then shallow copy
will suffice. You may find it easier to create new immutable objects
as needed than to deal with deep copies.

Yes, that's a good rule where it's applicable. Unfortunately there are
far too many situations where it isn't. Good design may reduce the
number, but it may not be able to eliminate them all.

Deep copies are a bit like pulling on a thread on a sweater. It can
just keep going and going unexpectedly far.

Quite right.


John Bollinger
(e-mail address removed)

 

[Chris Uppal]

Roedy Green wrote:

Quite right.

And a lovely analogy too.

-- chris

 

[Tris Orendorff]

Is there any kind of convention that dictates where it is usual to
perform shallow and deep copies?
I prefer to use copy constructors to implement any kind of copy, but
now I find the need for a shallow and deep copy in the same class.

Hi,

I only use deep copy when a method is recursive -- perhaps the board state of a game or some other
complex object where anything can be changed. I have never needed both shallow and deep cloning in
the same class before.

--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d++ s+:- a+ C+ UL++++ P+ L+ E- W+ N++ o- K++ w+ O+ M !V PS+ PE Y+ PGP t+ !5 X- R- tv--- b++
DI++ D+ G++ e++ h---- r+++ y+++
------END GEEK CODE BLOCK------