T_IMPORT vs. T_USE

Main problem I have right now after digging deeper is that any such "fix" in the parser will mean that tokenizers and syntax highlighters will not treat keywords like "import" correctly. Fixing this would require them to do parsing which in many cases you don't want to do. There are a lot of utilities and tools which depend on such behavior. Even if it's just for this reason it may be better if we stick to the "a keyword is a keyword" rule and don't try and outsmart ourselves (other languages like C have discovered the same issues and stuck to the keyword only rule too). So it may make most sense to go ahead and use "use". Andi

Stanislav Malyshev wrote:

Hi, If you're talking about my patch [1], the restriction is only lifted for method names. I don't think it is even possible for functions: function foreach() {return array(1);} foreach(foreach() as $oops); The above code requires PHP to parse all the way to the T_AS prior to determining whether the first foreach statement is a T_STRING or a T_FOREACH. It may be possible for classes, but is much more complex, so I did not go that route. For instance: class class { static function class(){} } $a = class::class(); $a = new class; We can safely expect a T_STRING after T_NEW, but in open global scope, we would need to match an identifier plus :: before matching any keyword. It is possible, but somewhat messier. Methods, on the other hand, are simple, as the 11-line patch demonstrates. We always know that stuff after T_OBJECT_OPERATOR and T_PAMMAYAMMAETC should be a T_STRING. In fact, this is already possible for variables as in this example (T_STRING returned for "class"): class blah { var $class; } $a = new blah; $a->class = 1; but as I said in the bug report, this example breaks (T_CLASS returned for "class"): class blah { var $class; } $a = new blah; $a-> class = 1; because the lexer fails to take into account whitespace properly when looking for a property (also fixed in my patch). Andi: your concern about highlighters is moot - implementing the changes to always detect T_STRING after :: or -> is trivial no matter how dumb the highlighter is :). Others: concern about T_IMPORT breaking BC is also moot. There is an instant parse error on this declaration: <?php namespace whatever; ?> The only way to "preserve" BC (no parse error) would be to use some weirdo syntax like <?php new namespace(whatever); ?> This might be an option, but I don't see much point - the code still will fail to work because it uses namespaces. Namespaces are new, the syntax *should* break BC, otherwise we'll get all kinds of weird bug reports from users using PHP versions that are too old. My patch prevents breakage of Zend Framework and Symfony because nobody who has followed the CS rule of "use underscores to avoid conflicting with internal classes" is using "class import" "class namespace" or interface equivalents. Greg [1] http://bugs.php.net/bug.php?id=28261