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.
> >>> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
