T_IMPORT vs. T_USE View as Markdown

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

-----Original Message-----
From: Stanislav Malyshev [mailto:stas@zend.com]
Sent: Wednesday, October 17, 2007 12:58 PM
To: Sebastian Nohn
Cc: Andi Gutmans; Johannes Schlüter; Sebastian Bergmann;
internals@lists.php.net
Subject: Re: [PHP-DEV] T_IMPORT vs. T_USE

Are there already any results on these checks?

Looks like we have the simple patch that allows to use "import" as
method name, function name and class name. If we didn't discover any
problems with it then import stays.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

Stanislav Malyshev wrote:

Are there already any results on these checks?

Looks like we have the simple patch that allows to use "import" as
method name, function name and class name. If we didn't discover any
problems with it then import stays.

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