Am 12.9.2013 um 22:44 schrieb Johannes Schlüter <[email protected]>:
> On Wed, 2013-09-11 at 23:21 +0200, Bob Weinand wrote:
>> Hi!
>>
>> I tried to widen the naming possibilities by allowing to use keywords
>> as identifiers (for function names, class names, label (goto)
>> names, ...) where possible. It doesn't break any BC.
>
> I often stumbled over the annoyance of this limitation and I know many
> users want it, I'm not convinced about adding it, though.
>
> One reason is the "where (easily) possible" part. Right now we have a
> simple rule "keywords can't be reused". This is being changed to "this
> and that keyword can be used her and there." I don't believe this is
> good.
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.
> Secondly I'm among the people who read tons of "bad" code and I'm sure
> people will abuse this and we will find code like this:
>
> <?php
> namespace network;
> function if($which) {
> // ... some logic ...
> return "eth0";
> }
> // ... somewhere else in the namespace ...
> if($condition);
> ?>
>
> This can hide subtile typos or coding errors. Also look at currently
> valid PHP code like this:
>
> <?php
> function while() {}
> $condition = true;
> while ($condition)
> ?>
>
> and while reading this mind that an ; in front of an ?> is optional, so
> will this call a function and exit or be stuck in an infinite loop?
>
> 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.
> 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.
> I couldn't test those examples as your branch for some reason didn't
> work, even though I made sure I regenerated the parser, but I didn't
> look deeper, maybe my fault.
>
> 001+ Parse error: syntax error, unexpected 'catch' (T_CATCH),
> expecting identifier (T_STRING) or \\ (T_NS_SEPARATOR) or '{'
> in /.../Zend/tests/identifier_or_keyword_001.php on line 3
> 001- Ok
> 002- Fatal error: %s in %s on line %d
>
> johannes
This sounds like some error while you were patching, because I cannot
reproduce any such problem here.
Bob Weinand