Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:32859
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 38.99.98.18 cause and error)
Message-ID: <471790C0.3020209@chiaraquartet.net>
Date: Thu, 18 Oct 2007 11:58:40 -0500
User-Agent: Thunderbird 1.5.0.13 (X11/20070824)
MIME-Version: 1.0
To: Stanislav Malyshev <stas@zend.com>
CC: Sebastian Nohn <sebastian@nohn.net>, Andi Gutmans <andi@zend.com>, 
 =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@php.net>, 
 Sebastian Bergmann <sb@sebastian-bergmann.de>,
  internals@lists.php.net
References: <fdohj3$bul$1@sea.gmane.org>	 <1191237850.2903.19.camel@johannes.nop>	 <698DE66518E7CA45812BD18E807866CEB9528E@us-ex1.zend.net>	 <4701E210.70109@nohn.net>	 <698DE66518E7CA45812BD18E807866CEB954E9@us-ex1.zend.net> <8c631e020710171158n25b5efedt4eccf7d816331407@mail.gmail.com> <47166930.7000706@zend.com>
In-Reply-To: <47166930.7000706@zend.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] T_IMPORT vs. T_USE
From: greg@chiaraquartet.net (Gregory Beaver)

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