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