Tony Marston wrote:
"Robert Cummings" <robert@xxxxxxxxxxxxx> wrote in message
Then you've got several options:
1) Don't upgrade PHP.
Not an acceptable option.
2) Pick a different hosting provider.
Not an acceptable optional.
3) Fix your scripts.
The scripts aren't broken. It's PHP 6 that's going to be broken.
I think you're missing the point of a full version increase. This is not a
minor or micro version change... script breakage is *expected*.
But breakage should be kept to an absolute minimum, and developer laziness
or incompetence is not an acceptable excuse.
Not quite true... major version moves are an opportunity to make a break
for freedom. All there needs to be is an upgrade path... and that is
clearly in play right now with the warning indicating that POSIX regex
functions are being deprecated.
You don't think PHP should support legacy cruft in the core forever do
you?
Widely use regex functions are not "legacy cruft". Besides, who decides what
is "cruft" and should be removed from the language?
They most certainly are cruft... hence the reason they are being
removed. The people who decide what is, and is not, cruft are the very
same people who are writing the code. If you are not happy with this
then there's the age old saying in open source... "put up or shut up".
If unicode support is slopped onto the current POSIX regex functions won't
that then make them non-POSIX? Food for thought. Also, why support two
libraries for which one is obviously inferior in speed and functionality?
That is why I suggested that instead of dropping the POSIX functions
entirely and seriously annoying lots of users, that they should simply be
rewritten as wrappers for the PCRE functions. In that way all the calls to
ereg_* would still work, but all they would do is immediately call the
relevant preg_* function. The small amount of effort that tghis would take
would kill two birds with one stone:
(1) There would be only one regex engine to support, which would be PCRE.
(2) Lots of developers would be spared the hassle of modifying their code as
all the calls to POSIX functions would still work as expected because the
language would redirect to the PCRE function automatically.
This would probably be worse than removing the POSIX functions. POSIX
and PCRE I daresay are not completely compatible. At least when you
remove the POSIX functions then the problem space is well defined.
Suddenly having POSIX regex functions that are really wrappers around
PCRE functions may introduce subtle differences in output for the same
horde of users but without the same explicability.
I am not suggesting that the POSIX functions be rewritten to deal with
unicode as that would require a huge amount of effort, but by redirecting al
POSIX calls to the equivalent PCRE function would have the same effect for
far less effort.
The choice is simple - either a small amount of effort from a small number
of developers, or a large amount of effort from a large number of seriously
pissed-off users. Do the maths. It's not rocket science.
This isn't a mathematical problem. It's a question of correctness. I
wasn't happy to hear POSIX regex functions were going either, but when I
heard the reasoning I did the best thing I could... I fixed my code to
prepare for the inevitable. There's no way I'd trust my code to "just
work" with POSIX functions redirected through PCRE and so I'd still need
to do the same legwork.
Wrapping the POSIX regex functions around PCRE will lead to more
problems than it solves IMHO.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
