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
> 
>