# RFC: Making T_FUNCTION optional in method declarations - Thread: https://externals.io/message/50628 - Original archive: https://news-web.php.net/php.internals/50628 - Started by johannes@schlueters.de on 2010-11-27T17:40:23+00:00 - Messages: 64 - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/50628.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #50628 — johannes@schlueters.de — 2010-11-27T17:40:23+00:00 URL: https://externals.io/message/50628#50628 Hi, every now and then while writing classes I forget to add the "function" keyword between my visibility modifier and the method name in a class declaration. I don't think it is required for readability and it is not needed by the parser to prevent conflicts, I therefore propose the following RFC incl. patch to allow writing class Foo { public bar() { echo "Hello World"; } } Without `T_FUNCTION` token. In my opinion an access modifier /public, private protected, static, final) should still be required for keeping readability. RFC: http://wiki.php.net/rfc/optional-t-function Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff johannes --- ## #50629 — Sebastian Bergmann — 2010-11-27T17:50:15+00:00 URL: https://externals.io/message/50628#50629 · In reply to: #50628 Am 27.11.2010 18:40, schrieb Johannes Schlüter: > RFC: http://wiki.php.net/rfc/optional-t-function > Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff +1 -- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ --- ## #50630 — Kalle Sommer Nielsen — 2010-11-27T17:52:12+00:00 URL: https://externals.io/message/50628#50630 · In reply to: #50628 2010/11/27 Johannes Schlüter : > RFC: http://wiki.php.net/rfc/optional-t-function > Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff +1, I've missed being able to skip the function keyword for a while now. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #50631 — Felipe Pena — 2010-11-27T17:53:34+00:00 URL: https://externals.io/message/50628#50631 · In reply to: #50628 2010/11/27 Johannes Schlüter > Without `T_FUNCTION` token. In my opinion an access modifier /public, > private protected, static, final) should still be required for keeping > readability. > > RFC: http://wiki.php.net/rfc/optional-t-function > Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff > > +1 -- Regards, Felipe Pena --- ## #50632 — Ilia Alshanetsky — 2010-11-27T17:54:31+00:00 URL: https://externals.io/message/50628#50632 · In reply to: #50628 As long as a modifier (public|private|protected) is still required, +1. 2010/11/27 Johannes Schlüter : > Hi, > > every now and then while writing classes I forget to add the "function" > keyword between my visibility modifier and the method name in a class > declaration. I don't think it is required for readability and it is not > needed by the parser to prevent conflicts, I therefore propose the > following RFC incl. patch to allow writing > >        class Foo { >            public bar() { >                echo "Hello World"; >            } >        } > > Without `T_FUNCTION` token. In my opinion an access modifier /public, > private protected, static, final) should still be required for keeping > readability. > > RFC: http://wiki.php.net/rfc/optional-t-function > Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff > > johannes --- ## #50633 — Pierrick Charron — 2010-11-27T17:55:58+00:00 URL: https://externals.io/message/50628#50633 · In reply to: #50628 +1 2010/11/27 Johannes Schlüter > Hi, > > every now and then while writing classes I forget to add the "function" > keyword between my visibility modifier and the method name in a class > declaration. I don't think it is required for readability and it is not > needed by the parser to prevent conflicts, I therefore propose the > following RFC incl. patch to allow writing > > class Foo { > public bar() { > echo "Hello World"; > } > } > > Without `T_FUNCTION` token. In my opinion an access modifier /public, > private protected, static, final) should still be required for keeping > readability. > > RFC: http://wiki.php.net/rfc/optional-t-function > Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff > > johannes --- ## #50634 — Pierre Joye — 2010-11-27T18:30:45+00:00 URL: https://externals.io/message/50628#50634 · In reply to: #50633 +1 if "While technically possible this RFC suggests that the following shall NOT be valid for keeping the code readable " also means that the patch implements it as well (force the function visibility property usage). 2010/11/27 Pierrick Charron : > +1 > > 2010/11/27 Johannes Schlüter > > > […] > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #50635 — Ross Masters — 2010-11-27T18:35:40+00:00 URL: https://externals.io/message/50628#50635 · In reply to: #50628 +1, has crossed my mind before =) "Johannes "Schlüter"" wrote in message news:1290879624.7033.826.camel@guybrush... Hi, every now and then while writing classes I forget to add the "function" keyword between my visibility modifier and the method name in a class declaration. I don't think it is required for readability and it is not needed by the parser to prevent conflicts, I therefore propose the following RFC incl. patch to allow writing class Foo { public bar() { echo "Hello World"; } } Without `T_FUNCTION` token. In my opinion an access modifier /public, private protected, static, final) should still be required for keeping readability. RFC: http://wiki.php.net/rfc/optional-t-function Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff johannes --- ## #50636 — johannes@schlueters.de — 2010-11-27T18:40:59+00:00 URL: https://externals.io/message/50628#50636 · In reply to: #50634 > +1 if "While technically possible this RFC suggests that the following > shall NOT be valid for keeping the code readable " also means that the > patch implements it as well (force the function visibility property > usage). The patch follows the RFC's suggestion. This option is mentioned to make it clear that this is a expected limitation if implemented. (And to allow other opinions, which I don't expect) johannes --- ## #50637 — Philip Olson — 2010-11-27T18:46:50+00:00 URL: https://externals.io/message/50628#50637 · In reply to: #50628 Sorry for moving offtopic, but if the PHP syntax is going to change then we should revisit other proposals that add/change syntax. For example, I think the short syntax for arrays was declined [from 5.3] mainly because it introduced a new syntax at a time we wanted to preserve BC: - http://wiki.php.net/rfc/shortsyntaxforarrays Regards, Philip --- ## #50638 — Marcello Duarte — 2010-11-27T20:32:44+00:00 URL: https://externals.io/message/50628#50638 · In reply to: #50628 +1 to being able to omit the function keyword. 2010/11/27 Johannes Schlüter : > Hi, > > every now and then while writing classes I forget to add the "function" > keyword between my visibility modifier and the method name in a class > declaration. I don't think it is required for readability and it is not > needed by the parser to prevent conflicts, I therefore propose the > following RFC incl. patch to allow writing > >        class Foo { >            public bar() { >                echo "Hello World"; >            } >        } > > Without `T_FUNCTION` token. In my opinion an access modifier /public, > private protected, static, final) should still be required for keeping > readability. > > RFC: http://wiki.php.net/rfc/optional-t-function > Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff > > johannes --- ## #50640 — Ferenc Kovacs — 2010-11-27T21:03:31+00:00 URL: https://externals.io/message/50628#50640 · In reply to: #50628 2010/11/27 Johannes Schlüter > Hi, > > every now and then while writing classes I forget to add the "function" > keyword between my visibility modifier and the method name in a class > declaration. I don't think it is required for readability and it is not > needed by the parser to prevent conflicts, I therefore propose the > following RFC incl. patch to allow writing > > class Foo { > public bar() { > echo "Hello World"; > } > } > > Without `T_FUNCTION` token. In my opinion an access modifier /public, > private protected, static, final) should still be required for keeping > readability. > > RFC: http://wiki.php.net/rfc/optional-t-function > Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff > > johannes > > Happened with me many times also. +1 for the feature. Tyrael --- ## #50639 — Ferenc Kovacs — 2010-11-27T21:05:48+00:00 URL: https://externals.io/message/50628#50639 · In reply to: #50637 2010/11/27 Philip Olson > Sorry for moving offtopic, but if the PHP syntax is going to change then we > should revisit other proposals that add/change syntax. For example, I think > the short syntax for arrays was declined [from 5.3] mainly because it > introduced a new syntax at a time we wanted to preserve BC: > > - http://wiki.php.net/rfc/shortsyntaxforarrays > > Regards, > Philip > -- > > > > I would love both feature, I think we should finalize the release process/roadmap, and after that, it would be a good idea to revisit the pending/declined rfc-s in the light of the roadmap. Tyrael --- ## #50641 — Jani Taskinen — 2010-11-27T21:22:57+00:00 URL: https://externals.io/message/50628#50641 · In reply to: #50628 +1 for PHP 7.0. :) Stuff like this accumulating in trunk kinda makes it more and more something else than minor release.. --Jani 27.11.2010 19:40, Johannes Schlüter kirjoitti: > Hi, > > every now and then while writing classes I forget to add the "function" > keyword between my visibility modifier and the method name in a class > declaration. I don't think it is required for readability and it is not > needed by the parser to prevent conflicts, I therefore propose the > following RFC incl. patch to allow writing > > class Foo { > public bar() { > echo "Hello World"; > } > } > > Without `T_FUNCTION` token. In my opinion an access modifier /public, > private protected, static, final) should still be required for keeping > readability. > > RFC: http://wiki.php.net/rfc/optional-t-function > Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff > > johannes --- ## #50642 — Mike Van Riel — 2010-11-27T21:58:51+00:00 URL: https://externals.io/message/50628#50642 · In reply to: #50628 On 27 nov 2010, at 18:40, Johannes Schlüter wrote: > Hi, > > every now and then while writing classes I forget to add the > "function" > keyword between my visibility modifier and the method name in a class > declaration. I don't think it is required for readability and it is > not > needed by the parser to prevent conflicts, I therefore propose the > following RFC incl. patch to allow writing > > class Foo { > public bar() { > echo "Hello World"; > } > } > > Without `T_FUNCTION` token. In my opinion an access modifier /public, > private protected, static, final) should still be required for keeping > readability. > > RFC: http://wiki.php.net/rfc/optional-t-function > Patch: http://schlueters.de/~johannes/php/ > zend_optional_t_function.diff > FWIW: +1 Though I do have two questions regarding behaviour: I am currently working on a documentation generator (DocBlox) which uses the tokenizer to analyze sourcefiles. The `T_FUNCTION` token is a clear sign for me that I am dealing with a method (as the visibility token can also be used with properties). With this patch I will loose this recognition point and the first solution that comes to mind is to search for () or arguments. This sounds rather hackish to me, might I be missing a solution? Another question is: when would you like to have this released? PHP- next? (thus either 5.4, 6, 7 or whichever is next?). Thank you! -- Kind regards, Mike van Riel --- ## #50643 — johannes@schlueters.de — 2010-11-27T22:14:34+00:00 URL: https://externals.io/message/50628#50643 · In reply to: #50642 > With this patch I will loose this recognition point and the first > solution that comes to mind is to search for () or arguments. This > sounds rather hackish to me, might I be missing a solution? The rule is something like [ `T_PUBLIC` | `T_PROTECTED` | `T_PRIVATE` | `T_STATIC` | `T_ABSTRACT` ] { & } `T_STRING` "(" param_list ")" { "{" statement_ist "}" } Where [] marks a choice of one or more and {} something optional. I think you could detect this similar to the way you're dealing with properties. If the `T_STRING` after the visibility modifier begins with a "$" it is a property, else it is a method. If the visibility modifier is followed by a "&" it is a method returning a reference. > Another question is: when would you like to have this released? PHP- > next? (thus either 5.4, 6, 7 or whichever is next?). I'd like it asap. But let's see where the version discussions go, I think this should be grouped together with Felipe's direct dereferencing of new objects etc. johannes --- ## #50644 — johannes@schlueters.de — 2010-11-27T22:21:22+00:00 URL: https://externals.io/message/50628#50644 · In reply to: #50643 > [ `T_PUBLIC` | `T_PROTECTED` | `T_PRIVATE` | `T_STATIC` | `T_ABSTRACT` ] { & } `T_STRING` "(" param_list ")" { "{" statement_ist "}" } I forgot `T_FINAL` there. johannes --- ## #50645 — Martin Wernstahl — 2010-11-27T23:13:55+00:00 URL: https://externals.io/message/50628#50645 · In reply to: #50644 @Johannes: The `T_STRING` token never contains "$", AFAIK all identifiers starting with "$" are instead classed as `T_VARIABLE` tokens. So you'd search for the visibility modifier (+ static, etc.) + `T_STRING` for methods, and visibility (+ static) + `T_VARIABLE` for properties. Martin 2010/11/27 Johannes Schlüter > > > > […] > `T_STRING` "(" param_list ")" { "{" statement_ist "}" } > > I forgot `T_FINAL` there. > > johannes --- ## #50647 — Daniel Convissor — 2010-11-28T01:43:40+00:00 URL: https://externals.io/message/50628#50647 · In reply to: #50628 Hi: > public bar() { Not that my vote really counts, but -1. Doing so would eliminate the helpful ability to grep source code for 'function bar'. --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 --- ## #50648 — Stas Malyshev — 2010-11-28T10:42:00+00:00 URL: https://externals.io/message/50628#50648 · In reply to: #50637 Hi! > Sorry for moving offtopic, but if the PHP syntax is going to change > then we should revisit other proposals that add/change syntax. For > example, I think the short syntax for arrays was declined [from 5.3] > mainly because it introduced a new syntax at a time we wanted to > preserve BC: I find it fascinating that a short time ago the short array syntax and other like proposals were unanimously rejected with "PHP needs no syntax sugar, everything should be explicit and verbose!" and now it's complete reversal - everybody supports syntax sugar, adding new complex syntax and what not. I personally am not sure this thing is worth doing, I never had a problem with typing "function" but if so many people do, maybe it's OK for a major version release. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #50649 — Ferenc Kovacs — 2010-11-28T11:11:04+00:00 URL: https://externals.io/message/50628#50649 · In reply to: #50648 On Sun, Nov 28, 2010 at 11:42 AM, Stas Malyshev wrote: > Hi! > > > Sorry for moving offtopic, but if the PHP syntax is going to change > > […] > > I find it fascinating that a short time ago the short array > syntax and other like proposals were unanimously rejected with "PHP > needs no syntax sugar, everything should be explicit and verbose!" and > now it's complete reversal - everybody supports syntax sugar, adding new > complex syntax and what not. > > I personally am not sure this thing is worth doing, I never had a problem > with typing "function" but if so many people do, maybe it's OK for a major > version release. > the answer is simple: The people who usually reject the proposals with that reason are: Johannes Schlüter Derick Rethans Richard Lynch Lester Caine and you Stas :) sorry if I wrong somewhere, I've just putting this list from my memory, because I can't search in google or gmail for +1/-1, maybe it would be a good thing, to put together a little statistic from the mailing list to show things like: who are the most active in the votes, who avarage vote by person, etc. ps: I didn't want to offend anybody, so I'm sorry if I did. Tyrael --- ## #50650 — Ferenc Kovacs — 2010-11-28T11:11:49+00:00 URL: https://externals.io/message/50628#50650 · In reply to: #50649 > > > On Sun, Nov 28, 2010 at 11:42 AM, Stas Malyshev wrote: > > > […] > > the answer is simple: The people who usually reject the proposals with that > reason are: > Johannes Schlüter > Derick Rethans > Richard Lynch > Lester Caine > and you Stas :) > > sorry if I wrong somewhere, I've just putting this list from my memory, > because I can't search in google or gmail for +1/-1, maybe it would be a > good thing, to put together a little statistic from the mailing list to show > things like: who are the most active in the votes, who avarage vote by > person, etc. > > ps: I didn't want to offend anybody, so I'm sorry if I did. > > Tyrael > ahh, I did forget to add Zeev to the list. :) Tyrael --- ## #50651 — Gustavo Lopes — 2010-11-28T11:14:28+00:00 URL: https://externals.io/message/50628#50651 · In reply to: #50648 On Sun, 28 Nov 2010 10:42:00 -0000, Stas Malyshev wrote: > Hi! > > > […] > > I find it fascinating that a short time ago the short array > syntax and other like proposals were unanimously rejected with "PHP > needs no syntax sugar, everything should be explicit and verbose!" and > now it's complete reversal - everybody supports syntax sugar, adding new > complex syntax and what not. In my opinion, the short array syntax is a completely different matter and we shouldn't be constantly diverting discussions... > > I personally am not sure this thing is worth doing, I never had a > problem with typing "function" but if so many people do, maybe it's OK > for a major version release. It's a completely redundant keyword, which I frequently forget and where I find no expressive power. But I also write a lot of Java, so I might be biased. I'm +0 on this. -- Gustavo Lopes --- ## #50652 — Daniel Convissor — 2010-11-28T14:02:01+00:00 URL: https://externals.io/message/50628#50652 · In reply to: #50647 Hi Again: > > Not that my vote really counts, but -1. Doing so would eliminate the > helpful ability to grep source code for 'function bar'. It also will trip up the multitude of PHP IDE's and editors. Plus it reduces code portability. All for saving us making a typo and having to write "function"? --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 --- ## #50654 — johannes@schlueters.de — 2010-11-28T14:29:39+00:00 URL: https://externals.io/message/50628#50654 · In reply to: #50652 > Hi Again: > > > > […] I can see this point. > It also will trip up the multitude of PHP IDE's and editors. Plus it > reduces code portability. All for saving us making a typo and having to > write "function"? PHP IDE's don't understand traits per se, they don't understand other changes per se. Code using new features won't work on older versions, but there's a way to be compatible. Depending on your requirements and likes. johannes --- Next page: https://externals.io/message/50628.md?page=2