Re: [pcre-dev] New API

On Sun, 19 Jan 2014, Giuseppe D'Angelo wrote:

> - Would it be possible to make the context an opaque type,

I was intending that the context should be an opaque type. That is why
the only way of accessing it is via function calls. Have you spotted
something in the document that contradicts this? (Granted, there's a
function that gives you its size, but that doesn't expose its layout.)

> - pcre2_set_global_options has somehow a misleading name (it doesn't
> set anything "global", it sets per-context pattern/matching options).

Good point. Perhaps pcre2_set_context_options would be better.

> - I don't personally like having several setter functions on the
> context (match limit, recursion limit, bsr, newline...) and one
> "universal" getter taking a macro. They should match 1:1.

It seemed to me that we were inventing a heck of a lot of functions, but
perhaps you are right. Matching set/get would be neater.

> - PCRE2_JAVASCRIPT_COMPAT: I honestly don't know enough about JS
> regexs to offer a good suggestion. But I don't think
> PCRE2_JAVASCRIPT_PATTERN is any better, on the contrary, it looks like
> we claim to be 100% compliant with ECMAScript pattern syntax rather
> than "aiming for compatibility"...

Indeed. I've just checked the 5 differences on the js on this box; the
first one (behaviour of ] when not in a class) is no longer an issue. So
we are left with (a) back reference to an unset capture and (b)
behaviour of \U, \u, and \x. There could be two separate options:

PCRE2_ECMASCRIPT_BACKREF
PCRE2_ECMASCRIPT_ESCUANDX

... or something.

> - Global substitutions: I'm not sure if we should provide a
> convenience for that, given that we don't provide a convenience for
> global match. (Which would be good, by the way).

A convenience for a global match would require some thought about how to
return the data. Perhaps a callback function for each match?

Philip

--
Philip Hazel