Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69105
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1379018669.12435.1710.camel@guybrush>
References: <BLU0-SMTP120B69BA7C5BC348F5D05DDE2390@phx.gbl>
	<1379018669.12435.1710.camel@guybrush>
Date: Thu, 12 Sep 2013 22:55:51 +0200
Message-ID: <CAF+90c_kJK0P_WwNdNRD5Wazrq0VvvopznrHsuus8JwrxVyT6Q@mail.gmail.com>
To: =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>
Cc: Bob Weinand <bobwei9@hotmail.com>, 
	Developers List PHP Mailing <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8f6436d29399e604e635f6ad
Subject: Re: [PHP-DEV] Support for keywords where possible
From: nikita.ppv@gmail.com (Nikita Popov)

--e89a8f6436d29399e604e635f6ad
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 12, 2013 at 10:44 PM, Johannes Schl=FCter
<johannes@schlueters.de>wrote:

> I often stumbled over the annoyance of this limitation and I know many
> users want it, I'm not convinced about adding it, though.
>
> One reason is the "where (easily) possible" part. Right now we have a
> simple rule "keywords can't be reused". This is being changed to "this
> and that keyword can be used her and there." I don't believe this is
> good.
>
> Secondly I'm among the people who read tons of "bad" code and I'm sure
> people will abuse this and we will find code like this:
>
>     <?php
>     namespace network;
>     function if($which) {
>         // ... some logic ...
>             return "eth0";
>      }
>      // ... somewhere else in the namespace ...
>      if($condition);
>      ?>
>
> This can hide subtile typos or coding errors. Also look at currently
> valid PHP code like this:
>
>     <?php
>     function while() {}
>     $condition =3D true;
>     while ($condition)
>     ?>
>
> and while reading this mind that an ; in front of an ?> is optional, so
> will this call a function and exit or be stuck in an infinite loop?
>
> I'm sure one could construct other such cases.
>
> I'm more open about allowing such identifiers as method names only, as
> those are prefixed in some way ($object-> or someClass:: ) but even
> there I tend to consider the consistency between function and method
> names more important than this flexibility.
>

I tend to agree with Johannes. Supporting different sets of keywords in
different locations is pretty confusing. Imho we should add this kind of
support only in places where a) we can support all keywords and b) it is
unlikely that supporting keywords there will cause issues in the future.

One such case are method names. Methods with keyword names are currently
callable using $foo->array(), because the identifier after
T_OBJECT_OPERATOR is always a T_STRING. But while you can call them, it is
currently not possible to define them as real methods. Instead you need to
forward them via __call magic, which is rather ugly. Internal classes on
the other hand can and do define methods with reserved-keyword names. E.g.
there is a Generator::throw() method.

Nikita

--e89a8f6436d29399e604e635f6ad--