Re: Support for keywords where possible
| From: | Bob Weinand | Date: | Fri, 13 Sep 2013 12:39:36 +0000 |
| Subject: | Re: Support for keywords where possible | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-69115@lists.php.net to get a copy of this message | ||
Am 13.9.2013 um 11:48 schrieb Johannes Schlüter <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
>>
>> 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.
>
> 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. … T_ELSE statement_list T_ENDIF ';'
that's why a T_ENDIF doesn't work at the beginning of an expression
>>> 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.
>
> 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.
>>
>> Yes, that is one of the main points.
>
> "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.
>
> johannes
Bob Weinand