Hi --

On Sat, 8 Feb 2003, Ryan Pavlik wrote:

> On Sat, 8 Feb 2003 08:15:08 +0900
>
> 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.

That means that if in 2.0 we go back to having Regexp#match provide
String objects in all cases, I have to anticipate that too....  I'm
not expecting this kind of flip-flopping, but the point is you *can't*
code defensively against all changes in the core language.  That's why
we have mailing lists to keep informed and discuss changes :-)

> > >   *  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?

I don't want to get into the whole design of scanf, which isn't
relevant, but in brief, Scanf::FormatSpecifier#to_i(s) is a private
method which returns s.to_i unless self matches /^\s*%\*/, in which
case it returns nil.  (See source for more detail.)

Keep in mind that I was expecting this method *not* to be called :-)
What I was expecting was String#to_i.


David

-- 
David Alan Black
home: dblack / candle.superlink.net
work: blackdav / shu.edu
Web:  http://pirate.shu.edu/~blackdav