Hi Philip,
On 13 January 2014 18:52, <ph10@???> wrote:
> Some months ago I published a document describing a possible new API for
> PCRE. I received some (not a lot) of feedback, but PCRE work then got
> sidetracked into bug fixes and performance improvements. I have now
> created a revised version of the document and put it here:
>
> ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/Testing/PCRE2_proposal.pdf
Some comments/questions.
- Would it be possible to make the context an opaque type, and
introduce a pcre2_create_context(pointer_to_private_malloc) function
to create a context object? pcre2_init_context(NULL) will then use
pcre2_create_context(system_malloc) and init the memory returned.
Rationale: making it a non-opaque type means breaking ABI
compatibility if/when the definition of such data type needs to
change, for instance for adding more fields. That's a huge problem for
Linux distributions and in general people wanting to dynamically
linking to libpcre2. Also, it mimics what pcre2_compile does.
- pcre2_set_global_options has somehow a misleading name (it doesn't
set anything "global", it sets per-context pattern/matching options).
- 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.
- 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"...
- 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).
Thank you again for your work,
--
Giuseppe D'Angelo
