Hi --

(Replying to two posts here.)

On Sat, 8 Feb 2003, Matt Armstrong wrote:

> J.Herre <jlst / gettysgroup.com> writes:
>
> > On Friday, February 7, 2003, at 08:05 AM, dblack / candle.superlink.net
> > wrote:
> >
> >>   class SpecializedString < String
> >>     def to_i(s)
> >>       # specialized overriding of to_i
> >>     end
> >>   end
> >>
> >>   s = SpecializedString.new("12345")
> >>   m = /(\d\d)/.match(s)
> >>   n = m[1].to_i
> >>   p n * 10
> >
> > This regexp change is actually very cool.  I've got some ugly code
> > that I can fix up as a result of this change.
> >
> > FWIW I think your example argues more strongly for adding
> > multi-dispatch to ruby (or maybe just adopting a policy of not

Yikes -- I assure you that's unintentional :-)

> > changing the semantics of well-known methods in subclasses) than for
> > backing out this change.

There's no way to define "well-known" robustly in that context,
though.  Also, even if the semantics weren't changed (I assume you
mean the argument count), presumably the overridden version would do
something different from the String version, so this 1.8.0 shift would
still have an impact.

I can always do:

  n = String.new(m[1]).to_i

but I'm not fond of it.

> At the risk of a "me too" post, I have the same thoughts.  Code should
> be able to do tests for object.kind_of?(String) and expect the methods
> of String to be present with similar semantics.

We're well into "agree to disagree" territory here :-)  I tend to look
at the behavior of Ruby objects as being very in-the-moment.  But in
any case, mainly I'm just wondering what the impetus was for this
particular change to #match (and #scan and #split).


David

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