Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69115
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.81 as permitted sender)
Message-ID: <BLU0-SMTP61C5B33E0D6EE9C456BB99E23B0@phx.gbl>
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
In-Reply-To: <1379065692.12435.2516.camel@guybrush>
Date: Fri, 13 Sep 2013 14:39:36 +0200
CC: Developers List PHP Mailing <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
References: <BLU0-SMTP120B69BA7C5BC348F5D05DDE2390@phx.gbl> <1379018669.12435.1710.camel@guybrush> <BLU0-SMTP412F6016490223CEEE14CF0E23A0@phx.gbl> <1379065692.12435.2516.camel@guybrush>
To: =?windows-1252?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>
Subject: Re: [PHP-DEV] Support for keywords where possible
From: bobwei9@hotmail.com (Bob Weinand)

Am 13.9.2013 um 11:48 schrieb Johannes Schl=FCter =
<johannes@schlueters.de>:
> On Fri, 2013-09-13 at 01:24 +0200, Bob Weinand wrote:
>> Here is a concrete list when keywords are allowed:
>> https://github.com/php/php-src/pull/438
>>=20
>> Then you should have a better idea what exactly will be allowed in =
future.
>>=20
>> Please go over the list and tell me explicitly what I should revert =
there.
>=20
> How would you teach that?

They're all keywords which depend on a keyword before while between them
can be an unlimited number of statements.

E.g. =85 T_ELSE statement_list T_ENDIF ';'=20
that's why a T_ENDIF doesn't work at the beginning of an expression

>>> I'm sure one could construct other such cases.
>>=20
>>=20
>> 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.
>=20
> This, in my opinion, is a major inconsistency, mess and no-go.

We have basically the choice:
 a) reject this patch
 b) just allow classes/traits/interfaces/goto-label/method to change, =
but no funcs/ns
 c) accept the whole patch

>>> 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.
>>=20
>> Yes, that is one of the main points.
>=20
> "Method names and properties can be made of keywords" is a rule I can
> live with, that's teachable, in itself consistent and almost always
> clearly readable. (exceptions are already unreadable code)
> I still have doubts about the inconsistency between function and =
method
> names then, which is why I'd be on -0.5.
>=20
> johannes


Bob Weinand=