jakarta-oro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff McNiel <JMcN...@datacrit.com>
Subject RE: Possible bug with Perl5Matcher and PatternMatcherInput
Date Tue, 04 Sep 2001 17:23:31 GMT
I certainly wouldn't object since that't the behavior I wanted,
but I really don't count being a first time user and all :-)

Cheers, Jeff

> -----Original Message-----
> From: Daniel F. Savarese [mailto:dfs@savarese.org]
> Sent: Saturday, September 01, 2001 1:13 AM
> To: oro-dev@jakarta.apache.org
> Subject: Re: Possible bug with Perl5Matcher and PatternMatcherInput 
> 
> 
> 
> In message 
> <095F1C2C73A3F84485C5838D4AC480D212D3AF@discovery.datacrit.com>, Jef
> f McNiel writes:
> >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.
> 
> Yes, that's the intended way to do it.  However, this point has been
> brought up before and it really does appear that it is more useful not
> to advance the offset.  It would also be more in keeping with 
> reproducing
> the behavior of \G and /g which PatternMatcherInput is intended to
> duplicate.  I just checked 'man perlop' and ran a little test 
> and contrary
> to my memory, \G does not change on failed matches.  At the time, it
> seemed more consistent and less surprising for
> contains(PatternMatcherInput,...) to always advance to where 
> the last match
> _attempt_ left off.  However, the primary reason an iterator 
> interface was
> not chosen was because of its inflexibility, but if 
> contains() fastforwards
> you to the end, although not as useless as an iterator, it makes life
> a bit more complicated because you have to reset the offsets yourself
> every single time.
> 
> I'm inclined to make the change because it makes lexical analysis and
> tokenizer construction easier.  I remember having an awkward 
> time writing
> a tokenizer because of this a few months ago.  The change 
> should not break
> most code that rewinds the offsets and will be advertised in both the
> javadocs and the CHANGES file.  Objections?
> 
> daniel
> 
> 

Mime
View raw message