Am 13.9.2013 um 11:48 schrieb Johannes Schlüter <johan...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
