Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69110
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.85 as permitted sender)
Message-ID: <BLU0-SMTP412F6016490223CEEE14CF0E23A0@phx.gbl>
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
In-Reply-To: <1379018669.12435.1710.camel@guybrush>
Date: Fri, 13 Sep 2013 01:24:48 +0200
CC: Developers PHP Mailing List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
References: <BLU0-SMTP120B69BA7C5BC348F5D05DDE2390@phx.gbl> <1379018669.12435.1710.camel@guybrush>
To: =?iso-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>,
 Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] Support for keywords where possible
From: bobwei9@hotmail.com (Bob Weinand)

Am 12.9.2013 um 22:44 schrieb Johannes Schl=FCter =
<johannes@schlueters.de>:
> On Wed, 2013-09-11 at 23:21 +0200, Bob Weinand wrote:
>> Hi!
>>=20
>> I tried to widen the naming possibilities by allowing to use keywords
>> as identifiers (for function names, class names, label (goto)
>> names, ...) where possible. It doesn't break any BC.
>=20
> I often stumbled over the annoyance of this limitation and I know many
> users want it, I'm not convinced about adding it, though.
>=20
> 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.

Here is a concrete list when keywords are allowed:
https://github.com/php/php-src/pull/438

Then you should have a better idea what exactly will be allowed in =
future.

Please go over the list and tell me explicitly what I should revert =
there.

> 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:
>=20
>    <?php
>    namespace network;
>    function if($which) {
>        // ... some logic ...
>            return "eth0";
>     }
>     // ... somewhere else in the namespace ...
>     if($condition);
>     ?>
>=20
> This can hide subtile typos or coding errors. Also look at currently
> valid PHP code like this:
>=20
>    <?php
>    function while() {}
>    $condition =3D true;
>    while ($condition)
>    ?>
>=20
> 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?
>=20
> I'm sure one could construct other such cases.


The "where (easily) possible" is exactly _not_ this. To call here the =
function
while you would have to write namespace\while(); (or call_user_func =
etc.)
I explicitly tried to not change the things where might be such =
collisions.
(That's what I meant with the "(easily) possible".)
So this is basically a non-issue, I think, as it is highlighted that =
it's a function
and not a language construct by the need to prefix this.

> 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.

Yes, that is one of the main points.

> I couldn't test those examples as your branch for some reason didn't
> work, even though I made sure I regenerated the parser, but I didn't
> look deeper, maybe my fault.
>=20
>        001+ Parse error: syntax error, unexpected 'catch' (T_CATCH),
>        expecting identifier (T_STRING) or \\ (T_NS_SEPARATOR) or '{'
>        in /.../Zend/tests/identifier_or_keyword_001.php on line 3
>        001- Ok
>        002- Fatal error: %s in %s on line %d
>=20
> johannes

This sounds like some error while you were patching, because I cannot
reproduce any such problem here.

Bob Weinand=