Overriding Object#clone vs. Overriding Object#dup for Deep-Cloning

Ruby
1

Hi.

Is there a community convention that specifies which of the two methods,
Object#clone and Object#dup, should be overridden for the purposes
of
deep-cloning?

On Stackoverflow, some say that clone should be overridden 1, while
others say that dup is the method to be overridden 2. So I suspect
that
there isn’t such a convention.

2

On Tue, Sep 18, 2012 at 9:20 PM, Yaser S. [email protected]
wrote:

Those answers are not good because in part they are just plain wrong.
There is no community convention either way that I am aware of.

My question for you would be: what do you need deep copying for? I
often find deep copy is a bit of a cargo cult approach: we simply grab
everything we can get so we are sure it’s ours. I have rarely - if at
all - felt the need for a deep copy; I usually prefer specific
functionality to handle state.

Kind regards

robert

3

both methods use internal an method called initialize_copy

so my opinion is to overwrite this method

4

@OP:

There is a dclone() method that is added to the Array class, by the
library file: “lib/rexml/xpath_parser.rb”

You could load that file, or steal the method definition for your own
custom Array subclass.

It is not a good idea to override Base class instance methods, but you
could if your code will not be released (used only internally.)

Changing base classes, in released packages, could interfere with other
packages. (Making users and other Ruby authors angry.)

General “rule of thumb”… if you can use a custom subclass, rather than
modifying a base class, than do so. (A must if your code runs within a
shared Ruby process where other authors code is also running, such as
Applications that run Ruby as an embedded scripting host.)