[RFC] Keywords as identifiers

php.internals

Bob Weinand

12 years ago
Hi! This is the (official) RFC thread for the patch proposed in http://php.markmail.org/message/7rn4mbwkbytqa3ig https://wiki.php.net/rfc/keywords_as_identifiers Any feedback about the RFC or the implementation? Bob Weinand

Stuart Langley

12 years ago
Hi Bob, It seems that the RFC does not [i'm quoting here from the template at ' https://wiki.php.net/rfc/template'] "explain hows the proposal brings * substantial* value to be considered for inclusion in one of the world's most popular programming languages." Perhaps I'm missing something completely obvious. To be honest, looking at the example in the RFC, being able to define a member function 'new' on a class that completely changes the semantics of the new operator is a great example of why you would not want this feature. Just my $0.02. Ciao, Stuart On Mon, Sep 16, 2013 at 10:53 PM, Bob Weinand <bobwei9@hotmail.com> wrote:

Matthew Leverton

12 years ago
On Tue, Sep 17, 2013 at 7:50 PM, Stuart Langley <slangley@google.com> wrote:
> To be honest, looking at the example in the RFC, being able to define a > member function 'new' on a class that completely changes the semantics of > the new operator is a great example of why you would not want this feature. >
It doesn't change anything because $foo->new() has no intrinsic meaning in PHP. And I don't think the argument "the programmer might do something stupid" ever holds much weight as a no vote against anything. If somebody wants to create a confusing misnomer, he doesn't need this proposed feature to do so. But I agree that the RFC is missing any real-world examples of why it might be useful, and that any new language feature should have real-world benefits. Hopefully some more compelling reasons will be added to the RFC. Here's something that I've personally done with much shame: class Where { private function _or($lhs, $op = null, $rhs = null) { } public function __call($func_name, $args) { if ($func_name == 'or') return call_user_func_array([$this, '_or'], $args); } } $query->where('foo', '=', 1)->or('bar', '=', 2); Imagine that $query->where() returns a Where object. I really want an "or" method because it make things concise & readable, but this is not allowed. So I override the __call method to add such functionality, which adds useless overhead. There are a few keywords, such as list and unset, that I often wish I could use in PHP. So in terms of readability, I think any sane programmer would use this proposed functionality for good...
-- Matthew Leverton

David Neilsen

12 years ago
"missing any real-world examples of why it might be useful" One thing the I have run across in making my libraries, is the not being able to call a function `default`. I use the chainable getter/setter in one syntax a lot (a la jQuery). Hence when I have a class with a property named default, and can not make a method in that sense. It makes my API inconsistent as I have to use a getDefault, setDefault, when every other method is a single word. Such as: class Foo { public $default; public function default($default = null) { if ($default === null) { return $this->default; } $this->default = $default; return $this; } } This might not be the prefered way to write methods, but I don't see why the language should restrict me from doing so because the word default is used in a different context. On Wed, Sep 18, 2013 at 5:19 PM, Matthew Leverton <leverton@gmail.com>wrote:

David Neilsen

12 years ago
*Should have been !== null On Wed, Sep 18, 2013 at 7:27 PM, David Neilsen <david@pan.co.nz> wrote:

Bob Weinand

12 years ago
Am 18.09.2013 um 09:28 schrieb "David Neilsen" <david@pan.co.nz>:
> "missing any real-world examples of why it might be useful" > > One thing the I have run across in making my libraries, is the not being > able to call a function `default`. > > I use the chainable getter/setter in one syntax a lot (a la jQuery). Hence > when I have a class with a property named default, and can not make a > method in that sense. It makes my API inconsistent as I have to use a > getDefault, setDefault, when every other method is a single word. > > Such as: > > class Foo { > public $default; > public function default($default = null) { > if ($default === null) { > return $this->default; > } > $this->default = $default; > return $this; > } > } > > This might not be the prefered way to write methods, but I don't see why > the language should restrict me from doing so because the word default is > used in a different context. > > > On Wed, Sep 18, 2013 at 5:19 PM, Matthew Leverton <leverton@gmail.com>wrote: > >> On Tue, Sep 17, 2013 at 7:50 PM, Stuart Langley <slangley@google.com> >> wrote: >>> To be honest, looking at the example in the RFC, being able to define a >>> member function 'new' on a class that completely changes the semantics of >>> the new operator is a great example of why you would not want this >> feature. >> It doesn't change anything because $foo->new() has no intrinsic >> meaning in PHP. And I don't think the argument "the programmer might >> do something stupid" ever holds much weight as a no vote against >> anything. If somebody wants to create a confusing misnomer, he doesn't >> need this proposed feature to do so. >> >> But I agree that the RFC is missing any real-world examples of why it >> might be useful, and that any new language feature should have >> real-world benefits. Hopefully some more compelling reasons will be >> added to the RFC. >> >> Here's something that I've personally done with much shame: >> >> class Where >> { >> private function _or($lhs, $op = null, $rhs = null) >> { >> } >> >> public function __call($func_name, $args) >> { >> if ($func_name == 'or') >> return call_user_func_array([$this, '_or'], $args); >> } >> } >> >> $query->where('foo', '=', 1)->or('bar', '=', 2); >> >> Imagine that $query->where() returns a Where object. I really want an >> "or" method because it make things concise & readable, but this is not >> allowed. So I override the __call method to add such functionality, >> which adds useless overhead. >> >> There are a few keywords, such as list and unset, that I often wish I >> could use in PHP. So in terms of readability, I think any sane >> programmer would use this proposed functionality for good... >> >> -- >> Matthew Leverton
Thank you all for your feedback; I was effectively missing a few concrete examples. I now added some examples. Bob Weinand

Nicolas Grekas

12 years ago
Hi Bob, thanks for the RFC! For those of us that use token_get_all(), will the newly allowed token appear as T_STRING or as T_%KEYWORD%? May I suggest you add a word about it in the RFC? As Ryan pointed out in the other thread, a T_%KEYWORD% has a high chance to break existing documentation generators or code parsers. As Nikita remembered us, "default" in $a->default is emitted as a T_STRING. It might be consistent to also emit a T_STRING on the new cases that you plan to allow? Regards, Nicolas

Bob Weinand

12 years ago
Am 18.09.2013 um 14:30 schrieb "Nicolas Grekas" <nicolas.grekas+php@gmail.com>:
> Hi Bob, thanks for the RFC! > > For those of us that use token_get_all(), will the newly allowed token > appear as T_STRING or as T_%KEYWORD%? > May I suggest you add a word about it in the RFC? > > As Ryan pointed out in the other thread, a T_%KEYWORD% has a high chance to > break existing documentation generators or code parsers. > > As Nikita remembered us, "default" in $a->default is emitted as a T_STRING. > It might be consistent to also emit a T_STRING on the new cases that you > plan to allow? > > Regards, > Nicolas
Absolutely true; this will still emit a keyword token. The reason is some limitation of the lexer which allows me to switch to a mode after I have encountered for example a :: (e.g. lookbehind), but it doesn't allow me lookaheads. If you have an idea how to circumwent that; I'm open to any suggestions. Bob Weinand

Ralph Schindler

12 years ago
http://news.php.net/php.internals/23254 -ralph On 9/16/13 7:53 AM, Bob Weinand wrote:

Jannik Zschiesche

12 years ago
Am Mittwoch, 18. September 2013 um 16:29 schrieb Ralph Schindler:
> http://news.php.net/php.internals/23254 > > -ralph > > On 9/16/13 7:53 AM, Bob Weinand wrote: > > Hi! > > > > This is the (official) RFC thread for the patch proposed in http://php.markmail.org/message/7rn4mbwkbytqa3ig > > > > https://wiki.php.net/rfc/keywords_as_identifiers > > > > Any feedback about the RFC or the implementation?
I really like the proposal. I cannot count how often I tried to create a class called „List“ and failed miserably. Cheers Jannik

Matt Ficken

12 years ago
I have run all the PHPT tests from the latest master test-pack against builds with this patch on Windows (all versions 2008+): I get the same failures I get from recent master builds. The patch doesn't break anything on Windows. You can get the PHP builds for Windows with this patch that I used here: http://windows.php.net/downloads/snaps/ostc/build/keywords/ When I first heard the title of the patch, it sounded like it was frivolous, but the examples of how it would be useful really show that it would be useful (fe List, doc generators, DSLs). I think this is a great change to the language.

Frank Liepert

12 years ago
> Hi! > > This is the (official) RFC thread for the patch proposed in > http://php.markmail.org/message/7rn4mbwkbytqa3ig > > https://wiki.php.net/rfc/keywords_as_identifiers > > Any feedback about the RFC or the implementation?
There is still an open request, see https://bugs.php.net/bug.php?id=28261. Maybe you can mention or even integrate it? What I dislike about the limited set of keywords is the reasoning. Language design shouldn't solely depend on technical limits/possibilities. if but not else/elseif? switch but not case? Imho the language design/semantics should be taken into consideration. One more thought: I think there must have been a reason for introducing keywords once. If so, has this reasoning become untenable? All in all I personally like the concept of keywords. They give some orientation, especially for beginners. More experienced programmers may see them as obstacles (in singular cases?). If widening keyword restrictions, then I would support johannes suggestion: method names only. Frank

Bob Weinand

12 years ago
Am 16.9.2013 um 14:53 schrieb Bob Weinand <bobwei9@hotmail.com>:
> Hi! > > This is the (official) RFC thread for the patch proposed in http://php.markmail.org/message/7rn4mbwkbytqa3ig > > https://wiki.php.net/rfc/keywords_as_identifiers > > Any feedback about the RFC or the implementation? > > Bob Weinand
I accidentally posted to the wrong thread; the discussion should be continued here… Quoting from the _wrong_ thread: I plan to move this rfc forward to voting phase in the next days. I have made some (huge) changes to the initial implementation over the last weeks. There initially was the problem that there were some ugly restrictions which keywords are allowed under which circumstances. They are now resolved (= all keywords possible except the ones which conflict with existing functionality). If there aren't any further objections now, I'll move it to voting phase. Bob Weinand

Patrick Schaaf

12 years ago
Hi, regarding the typehint issue mentioned in the RFC, I feel that it would be more consistent to handle that like the default/else goto label issue, i.e. disallowing class or interface names "array" and "callable" in the first place (and keeping the current behaviour of those when used as typehints). Otherwise, I would vote "yes" if I had voting rights :) best regards Patrick

Bob Weinand

12 years ago
Am 16.10.2013 um 23:53 schrieb Bob Weinand <bobwei9@hotmail.com>:
> Am 16.9.2013 um 14:53 schrieb Bob Weinand <bobwei9@hotmail.com>: > >> Hi! >> >> This is the (official) RFC thread for the patch proposed in http://php.markmail.org/message/7rn4mbwkbytqa3ig >> >> https://wiki.php.net/rfc/keywords_as_identifiers >> >> Any feedback about the RFC or the implementation? >> >> Bob Weinand > > I accidentally posted to the wrong thread; the discussion should be continued here… > > Quoting from the _wrong_ thread: > > I plan to move this rfc forward to voting phase in the next days. > > I have made some (huge) changes to the initial implementation over the last > weeks. > > There initially was the problem that there were some ugly restrictions which > keywords are allowed under which circumstances. They are now resolved (= all keywords possible except the ones which conflict > with existing functionality). > > If there aren't any further objections now, I'll move it to voting phase. > > Bob Weinand
I just wanted to note that I had added another section to the rfc today: https://wiki.php.net/rfc/keywords_as_identifiers#implementation (It is about the impact of having the logic in lexer instead of parser.) Bob Weinand