Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69114
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error)
To: Bob Weinand <bobwei9@hotmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, Developers PHP Mailing List
 <internals@lists.php.net>
In-Reply-To: <BLU0-SMTP412F6016490223CEEE14CF0E23A0@phx.gbl>
References: <BLU0-SMTP120B69BA7C5BC348F5D05DDE2390@phx.gbl>
	 <1379018669.12435.1710.camel@guybrush>
	 <BLU0-SMTP412F6016490223CEEE14CF0E23A0@phx.gbl>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 13 Sep 2013 11:48:12 +0200
Message-ID: <1379065692.12435.2516.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Support for keywords where possible
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

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