Re: [pcre-dev] PCRE 7.3 release candidate for testing

Top Page
Delete this message
Author: Philip Hazel
Date:  
To: Sheri
CC: pcre-dev
Subject: Re: [pcre-dev] PCRE 7.3 release candidate for testing
On Tue, 21 Aug 2007, Sheri wrote:

> Just a thought -- whatever's done, might want to also consider making it
> flexible enough to potentially support other external options in the
> future, especially if it has a positional requirement. E.g., Notempty is
> another option which could enhance end-user power. DupNames is another,
> though that one may generally need backend support.


DUPNAMES is already available via (?J).

You are pushing me in a direction in which I don't really want to go. I
still think the "right" way of doing all the options which apply to the
whole pattern (as opposed to being changeable within parts of it - as
(?J) is, incidentally) is for the application to have syntax that it
then passes in the options bits. I know the POSIX interface doesn't have
that - but then it is a weaker interface. I think I'm going to stick at
"you should use the native interface if you want all the fancy
facilities".

> About the metacharacter, you will never find (?>\r\n|[\r\n]) in a novice
> pattern.


Agreed! I'm waiting hear back from the Perl community on this one.

> Would a metacharacter for (?>\r\n|[\r\n]) work in a negated character
> class? Probably not, I see that \R is documented to mean "R" in a
> character class.


Like \R, it wouldn't work at all in a character class, because a
character class always matches ONE character.

Philip

--
Philip Hazel, University of Cambridge Computing Service.