Autor: ph10 Data: Dla: pcre-dev Temat: [pcre-dev] New API for PCRE
The PCRE maintainers have started a discussion about a revised API (something
that has been pending for a while) and I'd like to ask the community for
opinions on one particular point. But first, some background:
The current API dates from 1997 when I first implemented PCRE. It has proved
robust enough to last 16 years, with mostly compatible extensions. However,
there are some issues that cannot be fixed compatibly. There are also some
untidinesses in the code that it would be nice to fix.
We are proposing to design a new API that makes no attempt at compatibility,
but will hopefully be extensible enough to last for a long time, and at the
same time tidy up rough edges in the code. There are two possible ways of
releasing a new API, and this is where we would like some consumer feedback.
1. Release an entirely new library (let's call it NPCRE for now). This would be
completely separate from the existing library. Once the new library was
released, the old library would not be enhanced, and only security-critical
bugs would be fixed.
2. Release a library that somehow supports both APIs, probably with some kind
of "wrapper" that converts the old API to the new one. This should be
possible at least for the most common uses of PCRE, but it may not be
possible to implement an absolutely complete mapping.
The advantage of NPCRE is that the old library remains available unchanged for
existing code, and if bugs have to be fixed, this can be done without affecting
the new library. The disadvantage is the existence of two libraries, probably
for a very long time.
The advantage of 2 is that there is only one library to think about. The
disadvantage is that maintaining the old API has to be continually considered,
and this may tempt applications to stick with the old API (we would, of course,
like them to upgrade). Another disadvantage is that having both APIs available
could lead to bugs in programs that mix them up by mistake.
Whatever approach is taken, it is certain that applications using the old API
will be around for a very long time. This is something we just have to live
with. It is not without precedent: see Python 2/3, GTK 1/2, etc.
