Re: [pcre-dev] New API for PCRE

Góra strony
Delete this message
Autor: Thorsten Schöning
Data:  
Dla: pcre-dev
Temat: Re: [pcre-dev] New API for PCRE
Guten Tag Graycode,
am Samstag, 8. Juni 2013 um 19:42 schrieben Sie:

> OPCRE should have
> consideration for the POSIX API wrapper as well. Perhaps the existing
> C++ wrapper is in OPCRE too.


As POSIX and C++ alreaady are just wrappers around the old API, it
should be enough to let the old API be a wrapper around the new one.
The other wrappers should work out of the bov in this case.

> An application may use either OPCRE or NPCRE, but not both.


Why should one need that restriction if NPCRE already is a dependency
for OPCRE and therefore must be used in an application? Why shouldn't
one be able to use both APIs, especially with different function
names, if one is forced to build and link both libraries?

> The header
> #define values such as PCRE_CASELESS can be very different for OPCRE
> than for NPCRE.  Similarly, the header for OPCRE might:
>     #define pcre_compile(a,b,c,d,e) opcre__compile(a,b,c,d,e)
> in order to avoid conflict with function names in the libraries when
> OPCRE links in the NPCRE library.


It should be preferable to simply use new function names in the new
API, this way there won't be any naming collisions. And if the old
API is used in some kind of wrapper it's less work to leave everything
like function names structures, defines etc. as they are and map those
only if necessary to new names and structures. A new API doesn't
necessarily mean that every old define or structure need to change,
only those that behave differently.

> The documentation should state that OPCRE is transitional. At some
> future date the OPCRE project may be abandoned, or perhaps it will
> just remain static for very long intervals.


I don't see the benefit of an OPCRE for maintainers or users, users
who don't want or are able to upgrade at least should be in a position
to use the latest versions of "old PCRE" without changing any of their
infrastructure and this would mean that old PCRE simply stays
untouched as it is and the new API is simply that, a new library which
one can use or not.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning       E-Mail:Thorsten.Schoening@???
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/


Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow