Tony Marston wrote:
"Robert Cummings" <robert@xxxxxxxxxxxxx> wrote in message
news:4AF76E1F.2050700@xxxxxxxxxxxxxxxx
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.
But a lot of people won't see those warnings until they run 5.3.0 for the
first time. It is common practice, at least in all the other languages that
I have used, that is something is going to be removed that it is marked as
deprecated at the start of the previous release, not at the end. So marking
the POIX functions as deprecated should have happened in 5.0, not 5.3.
This is PHP, it is not all the other languages you have used. That said,
it will probably be at leats a year before PHP6 even thinks about being
released.
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.
That is just your opinion.
And the opposing opinion is your... all just opinions right?!
Other people think that PHP should be rewritten
so that it appears more like their favourite language. Among the suggestions
I have seen are:
- make all variables statically typed instead of dynamically typed.
- remove all procedural functions and make the language "pure" OO.
Who decides if they are right?
The PHP team... primarily those who contribute to the PHP cod itself.
Those people have earned the privilege of making final decisions.
.. 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".
I can't because I don't program in C. So I shall do the nextbest thing -
complain at every opporunity.
Then learn C... I see later in this email you whine and moan about
laziness... there is nothing stopping you from learning C but your own
laziness. If you lack the time to contribute... then perhaps you should
keep your mouth in check before calling the core developers lazy when
they probably have similar time constraints.
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.
"probably" and "daresay" mean that you are just guessing. According to some
people who know what they are talking about there is a one-for-one
comparison between each POSIX and each PCRE function.
And you are certainly guessing also. The thing about the future is that
it hasn't happened yet and so one can only provide opinion to predict
the unfolding of events.
At least when you remove the POSIX functions then the problem space is
well defined.
And lots of sers will be pissed off because they won'tbe able to upgrade to
PHP 6 without major programmer intervention.
This is opinion.
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.
"may introduce"? There you go, guessng again. Can you point out *any* POSIX
function that cannot be converted into PCRE?
No... I leave it to you to prove the reverse since YOU want the PHP team
to provide the wrappers. Don't be lazy... do the legwork. Show that one
can fully replace the other.
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.
Lot's of PHP users, myself included, do not think that it is "correct" to
remove widely used functionality just beause the developers are too lazy to
do a proper job.
Lots... are we talking 5? 10? 100? 1000? What the hell does lots mean?
Can you provide convincing statistics indicating this "group think"?
(aka "group OPINION").
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.
So you had to fix what wasn't broken just to circumvent a stupid decision by
the PHP developers.
No, I had to make my code future proof because a decision was made and
warning was given well in advance of it's coming. I decided not to be
lazy and procrastinate.
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.
So you wouldn't trust the PHP developers to write simple code which takes
each POSIX function and redirects it to a PCRE function? I have more faith
in their ability than I do yours.
I have great faith in the PHP developers... which is why I have trusted
their opinion to remove the POSIX functions. Obviously, YOU do not have
the same faith.
Wrapping the POSIX regex functions around PCRE will lead to more problems
than it solves IMHO.
IMHO your opinion does not carry much weight.
IMHO you're a juvenile troll that cries when he doesn't get his way.
Rather than put forth compelling evidence for why POSIX should be kept
or wrapped, you merely provide character attacks (calling the PHP
developers lazy) and your own lightweight and questionable opinions.
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
