Bug #7216: object.c defines clone method for objects that cannot be cloned.

• Status: Closed
• Assignee: matz (Yukihiro Matsumoto)
• Target version: -
• ruby -v: all versions up to current trunk
• Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN

[therevmj (Michael Johnson)]

As the subject says, in object.c, the clone method is defined and then special cased for certain object types. The end result is that all respond_to?(:clone) returns true for all objects, but then thows an fatal error in some cases. Here is an appropriate example:

a = true
=> true
a.respond_to?(:clone)
=> true
a.clone
TypeError: can't clone TrueClass
from (irb):3:in `clone'
from (irb):3

Ultimately, the objects that do no respond to 'clone' should have it removed so that the respond_to? method returns false.

[mame (Yusuke Endoh)]

• Status changed from Open to Assigned
• Assignee set to akr (Akira Tanaka)
• Target version set to 2.0.0

Akr-san, what do you think?

--
Yusuke Endoh [e-mail]

[akr (Akira Tanaka)]

2012/11/5 mame (Yusuke Endoh) [e-mail]:

Issue #7216 has been updated by mame (Yusuke Endoh).

Akr-san, what do you think?

It may be good idea.

The root problem is that Liskov substitution principle is violated
between Object and TrueClass.
(Object is clonable but its subclass, TrueClass, is not.)

So, such unprincipled classes may have responsibility to
undefine/unimplement methods which don't work.

I feel it's better to ask matz.

Tanaka Akira

[trans (Thomas Sawyer)]

This is true for class method #allocate too.

[mame (Yusuke Endoh)]

• Assignee changed from akr (Akira Tanaka) to matz (Yukihiro Matsumoto)
• Target version changed from 2.0.0 to 2.6

[naruse (Yui NARUSE)]

• Target version deleted (2.6)

[jeremyevans0 (Jeremy Evans)]

• Status changed from Assigned to Closed

Ruby started allowing clone on immediate values (true, false, nil, symbol, integer, float) in Ruby 2.4:

$ ruby23 -e 'p true.clone'
-e:1:in `clone': can't clone TrueClass (TypeError)
        from -e:1:in `<main>'
$ ruby24 -e 'p true.clone'
true