The tokenizer extension needs those, and changing it now would be breaking all scripts that make use of it. So there is little we can do here...

Derick

Hmm.  I'm convinced PHP should at least file a big fat
warning upon any attempted redefinition of a reserved
constant name, instead of ignoring the instruction
entirely.

Identifiers such as T_LIST are very often used in enums.

That is a good idea, thought it did that. Assigned.

Good, thanks.

Let me clarify -

PHP does log a NOTICE such as

[04-Feb-2003 17:18:22] PHP Notice:
  Constant T_LIST already defined
  in x.php on line 3

but this definitely needs to be a WARNING
or even an ERROR.

-Tomas

A notice is fine, we're not going to change this as it might break scripts out there.

A NOTICE definitely is NOT sufficient.

Remember many setups running older PHP software set
"error_reporting = E_ALL & ~E_NOTICE", because the
amount of notices on undefined array indices and
undefined variables can be quite overwhelming --
and it is precisely these setups that are likely
to be bitten by this problem.

Redefinition of a constant should be a WARNING,
I must insist.

It's fine as it is -> wont fix.

Guys, if this is how you deal with backwards
compatibility issues, then I'm scared.

I've been maintaining a big PHP project that's about
1MB of very clean code and I need to keep it alive.
This particular bug gave me quite a bit of a headache.
I've provided valid arguments on why a (trivial) change
should be made, and you seem to not really care.  That's
not giving me nice prospects into the future, is it?

Come on, we're talking about constants here!
If a constant is redefined by a program, then
that program is broken by definition and needs
to be told on an appropriate level.

How's changing a NOTICE into a WARNING going to break
anything, anyway?

diff -ur a/Zend/zend_constants.c b/Zend/zend_constants.c
--- a/Zend/zend_constants.c     2002-10-09 16:17:53.000000000 +0200
+++ b/Zend/zend_constants.c     2003-02-05 07:46:35.000000000 +0100
@@ -265,7 +265,7 @@
                if (!(c->flags & CONST_PERSISTENT)) {
                        zval_dtor(&c->value);
                }
-               zend_error(E_NOTICE,"Constant %s already defined", lowercase_name);
+               zend_error(E_WARNING, "Constant %s already defined", lowercase_name);
                ret = FAILURE;
        }
        free_alloca(lowercase_name);

> A notice is fine,

redefinition of a constant being only a NOTICE?  
you can't be serious!

In order to avoid breaking backward compatibility with existing scripts, would it not be possible to allow pre-defined constants to be hidden when a constant is defined in a script with the same name?  As long as a script doesn't need to use both the pre-defined constants, and the new ones, (which a script designed for an old PHP version should not need to do anyway), I can't think of any reason why that wouldn't be an almost perfect solution - problems would only occur if a script assumed that a constant which was not pre-defined, but not defined in the script, evaluated to it's own name.