[ruby-core:24685] [Bug #1844] Immediates Should Not Respond to :dup

Issue #1844 has been updated by Run Paint Run Run.


>> - Exceptions are expensive.
>> - Rescuing a specific exception requires a multi-line statement,
>> while respond_to? allows one to write "bar.foo if
>> bar.respond_to?(:foo)"
>
> But you probably wouldn't do:
>
>   x = y.dup if y.respond_to?(:dup)
>
> because if it didn't, you'd end up with nil.

The reason that I noticed this behaviour was because I had an Array that contained Fixnums, Floats, and Symbols, along with other objects. I wanted to #dup those that could be duplicated so I could process them safely. My instictual way to code this was ary.select{|e| e.respond_to?(:dup)}... Which failed. 

That Rails and other libraries implement their own approaches to this problem suggests that it needs fixing in the core. 

>> You say respond_to? is not always reliable. I think it should be reliable.
>
> I think that the exceptions and their messages can be useful in cases
> like:
>
>   (0.0..10.0).each {} # TypeError: can't iterate from float
>
> as opposed to having float ranges not respond to #each, and having to
> ask each range whether it responds to #each. I tend to see the
> immediate.dup thing as similar to that.

I disagree. This isn't about a specific invocation of an object, as is the case for Range objects with Float values; it's whole classes that never allow #dup to be called claiming that it can be, then raising when it is. These are two rather distinct cases. 

Either Jeremy's suggestion or fixing #respond_to? is fine by me.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/1844

----------------------------------------
http://redmine.ruby-lang.org