From: nobu.nokada@...
Date: 2002-12-13T15:19:57+09:00
Subject: Re: [RCR] Global Regexp Match Mechanism (//g)

Hi,

At Fri, 13 Dec 2002 14:13:07 +0900,
Matt Armstrong wrote:
> > String#index takes optional argument specifies searching
> > position.
> >
> >   pos = 0
> >   while foostr.index(/foo/, pos)
> >     puts $&
> >     pos = $~.end(0)
> >   end
> 
> The problem with String#index is:
> 
>     (a) if ruby is not run in ASCII mode, ruby must scan the whole
>         string up to 'pos' to find the correct byte offset
>         (e.g. utf8_startpos() in regex.c)

I know, and it has improved in 1.7.

>     (b) there is no way to anchor the regex at 'pos'
> 
>             "abcd".index(/\Abc/, 1) -> nil
>             "abcd".index(/^bc/, 1)  -> nil

"abcd".index(/\Gbc/, 1) -> 1

> Because of these problems, an API like Perl's pos() and \G is
> desirable.  For example:
> 
>     (1) Have the string remember its last end-of-match position (byte
>         and offset).  This fixes problem (a) above.

But thread unsafe.

>     (2) In regexps, \G match this position.  This fixes problem (b).

Already it does.

>     (3) Have String#gpos (or better name) set/get the end-of-match
>         position based on a character index, for convenience.

It doesn't seem a good interface to me.

> This begins to look a lot like strscan, which will be part of ruby
> 1.8.  However, because strscan is not part of String, it can not know
> when the string is modified and must freeze the string before
> operating on it (otherwise it risks having its byte offsets be
> incorrect when the string is modified).
> 
> Freezing the string is inconvenient in my application.  I examine a
> string in detail before deciding whether to append more data to it
> (String#<<) from a file or start a new string.

Modification of target string will cause the character boundary
issue even with your String#gpos.  It must be recalculated.

-- 
Nobu Nakada