You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oro-dev@jakarta.apache.org by Jeff McNiel <JM...@datacrit.com> on 2001/09/01 00:56:18 UTC
RE: Possible bug with Perl5Matcher and PatternMatcherInput
Daniel, Thanks for the response,
Yes, I knew that contains advances the current offset when it matched.
I was counting on that to get a result like:
...
Real: 1.0
String: is
Integer: 2
...
out of the modified prefixExample.java instead of what I got:
One approach.
Real: 1.0
An equivalent alternative.
String: Test
String: to
...
I see now that what is happening: when contains() does not match,
it sets the currentOffset of the PatternMatcherInput to "past the end"
I suppose that this is the correct behavior as designed - just my
misunderstanding :-) (suggestion for the docs - nothing is said about
changing the offset in the case of match failure)
I guess to get the behavior I want, I'll have to save the currentOffset
and reset it on match failure.
Thanks again - Jeff
> -----Original Message-----
> From: Daniel F. Savarese [mailto:dfs@savarese.org]
> Sent: Friday, August 31, 2001 1:32 PM
> To: oro-dev@jakarta.apache.org
> Subject: Re: Possible bug with Perl5Matcher and PatternMatcherInput
>
>
>
> In message
> <09...@discovery.datacrit.com>, Jef
> f McNiel writes:
> >This can be reproduced by changing the file:
> >
> > jakarta-oro-2.0.4/src/java/examples/prefixExample.java
> >
> >to use contains() instead of matchesPrefix() in the "first" approach.
>
> matchesPrefix() does not advance the current offset. contains() does.
> With contains(), every subsequent match picks up from where the last
> successful match left off regardless of what pattern you are using.
> If you want to start from the beginning again, you have to reset the
> PatternMatcherInput current offset to the beginning. So
> prefixExample.java
> will behave completely differently when matchesPrefix() is changed to
> contains().
>
> >There seems to have been a relativly big change between 2.0
> >and 2.0.4 in re the __initInterpreterGlobals business and the
> >use of [__]currentOffset vs. [__]beginOffset - I suspect something
>
> There shouldn't be anything wrong there. The changes after 2.0 fix
> a problem with anchors (see the CHANGES file). If you find anything
> else that you think is a problem, post some sample code and input
> reproducing the problem and we'll have at it. At this stage
> (maintenance mode), almost all problems tend to be misunderstandings
> because of lack of better examples and a user's guide. But we'll fix
> that soon enough and start breaking things once the Perl 5.6
> compatibility effort begins in earnest and we enter development mode
> again.
>
> daniel
>
>