On 3/29/06, Robert Dober <robert.dober / gmail.com> wrote:
> (A) Somebody might rely on
>    "a" =~ nil returning false
> in that case abandon!!! (and ask yourself why you have posted that
> question!)

I don't think anyone's code will rely on "a" =~ nil returning false.
However, it's possible and even likely that someone's code will rely
on "a" =~ not_a_regex not raising an exception For instance,
REXML::Light::Node supports #=~, as mentioned in my previous post. I
wouldn't take kindly to an "extension" that breaks REXML.

> (B) Matching with nil is probably a mistake that will break the code later,
> in other words your astonishement about that behaviour will be "common
> sense", in that case the above extension of a core class is just a great
> idea.

I agree matching with nil is probably never the intended usage.
Perhaps String#=~ should be patched specifically to not allow nil. The
current behavior is a side effect of nil being an Object and thus
inheriting Object#=~.

However, I disagree with the sweeping "extension" whereby anything
that's not a Regexp causes String#=~ to raise an exception. I take
this as an example of how tricky it can be to *safely* "extend" the
core modules. This doesn't mean you can't do it, just that you should
be *very careful.

Jacob Fugal