On 10/30/2010 02:09 AM, Mike Van Riel wrote:
On 30 okt 2010, at 08:34, Sebastian Bergmann <sebast...@php.net> wrote:
On 10/30/2010 11:53 AM, Andi Gutmans wrote:
I would prefer this was not changed.
+1 (for the same reasons)
I agree with Andi, Rasmus and the other people in favor.
This token name is part of the history of PHP and adds to it's
uniqueness.
But besides this: renaming the constant is probably not going to solve
the problem (at least not anytime soon).
Changing this constant would mean breaking BC (some people using the
tokenizer extension might use it) and thus officially it should only
be implemented in PHP-next.
This means that the support requests will be coming in for a long time
as it not even planned for release or anything.
Suppose that this rename would happen in the next minor release: most
shared hosts lag immensily with their installed PHP version and I
reckon most questions come from inexperienced / starting developers
working with / on said hosts. And this means it will again take a long
time before you notice any effect. (not to mention that Linux distros
also lag).
(additionally I wonder why people ask such a simple question on IRC
whilst googling provides your answer faster..)
Bottom line: I'd opt for keeping it.
Kind regards,
Mike van Riel
Just want to make this point: the length of time for it to take affect
is not an argument for not implementing it. It'll come out when it's
out. The sooner we implement it, the sooner we'll notice the effect.
This goes for any change slanted for major release.
(Also if I understand, there is a synonym in Tokenizer anyway so both
would work and won't break BC, I just don't understand why the confusing
name has to show up in error messages).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
