Re: Support for keywords where possible
| From: | Johannes Schlüter | Date: | Fri, 13 Sep 2013 09:48:12 +0000 |
| Subject: | Re: Support for keywords where possible | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-69114@lists.php.net to get a copy of this message | ||
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?
> > 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.
> > 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.
> > 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.
> This sounds like some error while you were patching, because I cannot
> reproduce any such problem here.
as said: could be my fault :)
johannes