Hi --

On Sun, 2 Aug 2009, Run Paint Run Run wrote:

> I wrote:
>>
>> 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.

Yes and no. There could be a FloatRange class that doesn't mix in
Enumerable, or something like that. It doesn't really matter how it's
implemented; the point is that you can't do:

   ranges.each {|r| r.map ... }

with an array of ranges, without risking an exception, just as you
can't dup each of an array of arbitrary objects without that risk.

> Either Jeremy's suggestion or fixing #respond_to? is fine by me.

It's not really fixing #respond_to? (which is correctly reporting that
these objects can resolve the message "dup"). It would be a matter of
undef'ing #dup for certain classes. I have mixed emotions about it. On
the one hand, if (say) nil can't be duped, there's no really
compelling reason for it to respond to #dup. On the other hand,
there's a pretty common pattern of methods defined in Object that
exist mainly to be overridden (to_s, inspect, ==, ===, etc.). Usually
they're not overridden to raise an exception, but there's no
underlying reason why they shouldn't be.


David

-- 
David A. Black / Ruby Power and Light, LLC / http://www.rubypal.com
Q: What's the best way to get a really solid knowledge of Ruby?
A: Come to our Ruby training in Edison, New Jersey, September 14-17!
    Instructors: David A. Black and Erik Kastner
    More info and registration: http://rubyurl.com/vmzN