Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69120
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.86 as permitted sender)
Message-ID: <BLU0-SMTP158C7B336FEAF402E3EB989E23B0@phx.gbl>
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
In-Reply-To: <1379079098.12435.2767.camel@guybrush>
Date: Fri, 13 Sep 2013 16:18:06 +0200
CC: Developers Mailing List PHP <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> <BLU0-SMTP61C5B33E0D6EE9C456BB99E23B0@phx.gbl> <1379079098.12435.2767.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 15:31 schrieb Johannes Schl=FCter =
<johannes@schlueters.de>:
> On Fri, 2013-09-13 at 14:39 +0200, Bob Weinand wrote:
>> 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?
>>=20
>> They're all keywords which depend on a keyword before while between =
them
>> can be an unlimited number of statements.
>>=20
>> 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
>=20
> Consider Average Joe trying to extend some application, so he writes
>=20
>   <?php
>   namespace someApp\Actions;
>   function default() {
>   }
>   function secondary() {
>   }
>   function another() {
>       // ...
>       secondary();
>       // ...
>   }
>=20
>   namespace someApp\Controller;
>   function foo() {
>       someApp\Actions\default();
>   }
>=20
> now a year later Programmer Smith comes along and changes this
>=20
>   <?php
>   namespace someApp\Actions;
>   function new() {
>       if ($condition) {
>           secondary();
>       } else {
>           default();
>       }
>   }
>=20
> and will have a hard time to understand.

Agree.

>>>>> 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.
>>=20
>> 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
>=20
> Option b) might also include class constants, I think. If we really =
want
> this I'd still suggest to limit it to method names (and maybe class
> constants) first as those are always properly scoped and then for a
> later version evaluate the amount of (ab)use (as much as we can see
> that ..), the headache for tools (code analyzers, IDEs, ..) and then
> probably extend it.
>=20
> If it's my own free choice I wouldn't add it at all.
>=20
> johannes

I think we should choose option b). Yes; forgot to list the class =
constants.

Will remove support for unlimited function names etc.  then tomorrow if =
no-one has a
better idea.

What then would be still supported exactly is
with the restricted list:
- typehint
- class/trait/interface names
- goto-label

unrestricted:
- method names
- constant names
- property names
- trait aliases
- declare list
(- argument names if we use identifier =3D> $value syntax for named =
args)

I think this is a good compromise.

Bob Weinand=