From: John Halderman <jhalderman@...>
Date: 2005-07-23T05:13:47+09:00
Subject: Re: Possible bug with StringScanner class

------=_Part_901_33088074.1122063180543
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 7/22/05, Eric Mahurin <eric_mahurin@yahoo.com> wrote:
>=20
> --- John Halderman <jhalderman@gmail.com> wrote:
>=20
> > I'm not sure if this is a bug or intentional behavior, so I
> > thought I would
> > post it here to see what the community thought of what was
> > happening. If you
> > set up a StringScanner object to perform iterative matching
> > on a string the
> > behavior of \A and ^ seem to always match. It seems to me
> > that \A should
> > only match if it is the first match performed, and ^ should
> > only match if
> > bol? returns true, which should be after a \n or if it is the
> > first match
> > performed.
>=20
> You should think of the current position as the beginning of
> the string for matching. In addition, the regexp that scan
> gets is implicitly anchored to that spot. So specifiing \A or
> ^ at the beginning of a regexp for scan is redundant.


There is nothing in the documentation to suggest that the current position=
=20
should be considered the beginning of a string for matching purposes, only=
=20
that any match must start at that position. That would mean a regexp=20
beginning with ^ would need the current position to be preceded by \n or be=
=20
the at the beginning of the string in order for it to match. Furthermore,=
=20
the existence of bol? suggests that the current position is not to be=20
considered the beginning of the line. As for whether is should be considere=
d=20
the beginning of the string, that remains ambiguous, although I believe it=
=20
makes more sense for it not to be so.=20

> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - Find what you need with new enhanced search.
> http://info.mail.yahoo.com/mail_250
>=20
>

------=_Part_901_33088074.1122063180543--