From: Austin Ziegler Date: 2004-08-23T09:09:41+09:00 Subject: Re: Regexp scanning with MatchData (Re: multiple regexp matches) On Mon, 23 Aug 2004 07:33:18 +0900, nobu.nokada@softhome.net wrote: > At Sun, 22 Aug 2004 14:00:45 +0900, > Austin Ziegler wrote in [ruby-talk:110110]: > > Proposal: > > String#scan, #sub, and #gsub > > yield MatchData objects instead of Strings. I think that this could be > > achieved while breaking the least amount of code by adding a #to_str > > implementation to MatchData. > #to_str doesn't solve everything. MatchData#[] returns a matched > portion for sub-patterns, whereas String#[] returns a byte at > the position. Agreed. It also is 100% incompatible on #scan with groups in the regexp (e.g., "foobar".scan(/(..)(.)/) will yield [["fo", "o"], ["ba", "b"]]. This is the argument for Regexp#scan instead of modifying String#scan. However, this is something that I believe should be changed. An alternative is to yield both the normal values and the match -- but that itself will be incompatible with #scan and most current uses of #gsub and #sub that use the match value. Yet another alternative is to add an optional parameter in all cases. String#gsub currently expects a regexp and a replace pattern OR a regexp and a block. #gsub could be modified such that when it gets a regexp, a "boolean", and a block, it yields something different. This could be, for example: String#gsub(pattern, true) { |match_data| ... } String#gsub(pattern) { |string| ... } I would actually rather see the opposite form, if we do this: String#gsub(pattern, true) { |string| ... } String#gsub(pattern) { |match_data| ... } This would encourage the use of the new form. By doing it this way, a transition period can be introduced for this (e.g., it in 1.8.3 it may warn that the current replace will be changed to yield a match_data instead of a string; in 1.9 it yields a match_data instead of a string). I have *not* analysed code out there that uses #gsub/#scan/#sub, but I think that this is an ideal change. -austin (I'm also adding this to the discussion on RCR276) -- Austin Ziegler * halostatue@gmail.com * Alternate: austin@halostatue.ca