On Sat, 8 Feb 2003 08:15:08 +0900
dblack / candle.superlink.net wrote:

<snip> 
> We're getting tied in unnecessary and irrelevant knots here.
> 
> My code *does* take everything in stride, and work correctly, in Ruby
> 1.6.8.  There is a change in Ruby 1.8.0 that makes it not work.  I
> don't think I can be expected to have anticipated this change when I
> wrote the code in August.

Perhaps not, but IMHO it's more useful to have the new behavior.

Focusing on this change seems a bit of a red herring to me... if you've
changed SpecializedString#to_i, is it not possible to use your new
semantics?  Or is it not possible to provide the old behavior as a
default? You _should_ predict problems a change in #to_i semantics might
cause, because semantic changes usually cause problems.

> My code was not "trying to do something that's not allowed."  I did
> not change the semantics of String#to_i; I subclassed String and
> overrode a method.  String#to_i is completely unchanged.

Well, it seems logical that if you're working with SpecializedString,
it's natural that operations on itself return other SpecializedString
objects.  This seems to be a positive change in 1.8.  Is it not possible
for your code to work with the SpecializedString class in these cases?

> >   *  Changing a method to do something illogical is possible but
> >      questionable.
> 
> This is of course true, but very far afield from my question.

True, but I was addressing the quote "presumably the overridden version
would do something different from the String version".  Such a change
is illogical... if to_i no longer converts the string to an int, what
does it do?

> To bring us back on track: what we're discussing is not whether or how
> to override methods in subclasses, but the relative merits of the two
> behaviors of Regexp#match.  Either behavior can be accomodated; I
> simply want to know the history of why the new one was chosen.
<snip>

Ah.  Well, the reason above sprang to mind for me; I'll be interested
to hear the real reason. ;)  Just my 0b10.

-- 
Ryan Pavlik <rpav / users.sf.net>

"Are there no depths that you won't sink to?
 - We won't know 'till we get there!" - 8BT