Hi --

On Sun, 18 Feb 2007, Robert Dober wrote:

> On 2/17/07, Dean Wampler <deanwampler / gmail.com> wrote:
>> 
>> As someone else commented, perhaps the real issue is that
>> 5.respond_to?(:dup) returns true yet 5.dup raises, so you have no way
>> of knowing in advance that you shouldn't call dup.
> That just came up recently and I agree that this is kind of inelegant
> (euphemistically)
> Maybe that would be a reasonable CR?

See Ara's answer to Dean, though.  respond_to? isn't designed to tell
you what will happen when you call the method.  Lots of objects
respond to methods by raising exceptions.

Maybe the reason people don't like dup doing that is that it *always*
does it for some classes of object.  But I think that's in order to
leave no mysteries.  dup is "advertised", so to speak, as something
that every object can do.  So when an object can't do it, it's more
gracious to explain why not (in the exception message).

It's a lot like this:

   irb(main):001:0> (0..10).to_a
   => [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
   irb(main):002:0> (0.0..10.0).to_a
   TypeError: can't iterate from Float

Ranges with floats in them could just undef to_a and not respond, but
the expectation exists that all ranges have some meaningful
relationship to the process of being converted into an array
(including the relationship of opting out of it but in a way that
tells you what's going on).

I realize that two ranges are of the same class while, say, a string
and nil aren't.  But it's not a class thing; it's more about
collective (not necessary along class lines) behaviors and
expectations.


David

-- 
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
    (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)