Am 13.9.2013 um 15:31 schrieb Johannes Schlüter <johan...@schlueters.de>: > On Fri, 2013-09-13 at 14:39 +0200, Bob Weinand wrote: >> 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 > > Consider Average Joe trying to extend some application, so he writes > > <?php > namespace someApp\Actions; > function default() { > } > function secondary() { > } > function another() { > // ... > secondary(); > // ... > } > > namespace someApp\Controller; > function foo() { > someApp\Actions\default(); > } > > now a year later Programmer Smith comes along and changes this > > <?php > namespace someApp\Actions; > function new() { > if ($condition) { > secondary(); > } else { > default(); > } > } > > and will have a hard time to understand.
Agree. >>>>> 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 > > 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. > > If it's my own free choice I wouldn't add it at all. > > 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 => $value syntax for named args) I think this is a good compromise. Bob Weinand -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
