Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
2010/11/30 Kalle Sommer Nielsen ka...@php.net:
Hi
2010/11/30 Patrick ALLAERT patrickalla...@php.net:
With this patch, something looks inconsistent to me:
Both properties and methods have a visibility
(public|protected|private) and a keyword: var (T_VAR) and function
(T_FUNCTION) respectively.
However private var $foo; generates a fatal error but private
function foo(){} not?
The var keyword is an alias of the public keyword for BC with
PHP4. So it would be illogically to declare a property both private
and public at the same time ;-)
Shouldn't we get rid of that kind of pre-PHP5 stuff _before_
introducing the possible omission of T_FUNCTION?
Patrick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
I toast to that. Get rid of T_VAR already.
Regards,
David
On Thu, Dec 2, 2010 at 3:34 AM, Patrick ALLAERT patrickalla...@php.netwrote:
2010/11/30 Kalle Sommer Nielsen ka...@php.net:
Hi
2010/11/30 Patrick ALLAERT patrickalla...@php.net:
With this patch, something looks inconsistent to me:
Both properties and methods have a visibility
(public|protected|private) and a keyword: var (T_VAR) and function
(T_FUNCTION) respectively.
However private var $foo; generates a fatal error but private
function foo(){} not?
The var keyword is an alias of the public keyword for BC with
PHP4. So it would be illogically to declare a property both private
and public at the same time ;-)
Shouldn't we get rid of that kind of pre-PHP5 stuff _before_
introducing the possible omission of T_FUNCTION?
Patrick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT patrickalla...@php.netwrote:
2010/11/30 Kalle Sommer Nielsen ka...@php.net:
Hi
2010/11/30 Patrick ALLAERT patrickalla...@php.net:
With this patch, something looks inconsistent to me:
Both properties and methods have a visibility
(public|protected|private) and a keyword: var (T_VAR) and function
(T_FUNCTION) respectively.
However private var $foo; generates a fatal error but private
function foo(){} not?
The var keyword is an alias of the public keyword for BC with
PHP4. So it would be illogically to declare a property both private
and public at the same time ;-)
Shouldn't we get rid of that kind of pre-PHP5 stuff _before_
introducing the possible omission of T_FUNCTION?
Why?
This will break lots of code, does it improve anything while at it? Is 'var'
hindering anything? Is it taking up a lot of code?
If it is removed then that should be in trunk aka 6.0 the 2nd , and not in
5.x.
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
How about deprecation then?
On Thu, Dec 2, 2010 at 3:58 AM, André Rømcke a...@ez.no wrote:
On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT patrickalla...@php.net
wrote:
2010/11/30 Kalle Sommer Nielsen ka...@php.net:
Hi
2010/11/30 Patrick ALLAERT patrickalla...@php.net:
With this patch, something looks inconsistent to me:
Both properties and methods have a visibility
(public|protected|private) and a keyword: var (T_VAR) and function
(T_FUNCTION) respectively.
However private var $foo; generates a fatal error but private
function foo(){} not?
The var keyword is an alias of the public keyword for BC with
PHP4. So it would be illogically to declare a property both private
and public at the same time ;-)
Shouldn't we get rid of that kind of pre-PHP5 stuff _before_
introducing the possible omission of T_FUNCTION?
Why?
This will break lots of code, does it improve anything while at it? Is
'var'
hindering anything? Is it taking up a lot of code?
If it is removed then that should be in trunk aka 6.0 the 2nd , and not
in
5.x.
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
2010/12/2 André Rømcke a...@ez.no: On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT patrickalla...@php.net wrote: Shouldn't we get rid of that kind of pre-PHP5 stuff _before_ introducing the possible omission of T_FUNCTION? Why? This will break lots of code, does it improve anything while at it? Is 'var' hindering anything? Is it taking up a lot of code? If it is removed then that should be in trunk aka 6.0 the 2nd , and not in 5.x. It should of course not appear in a 5.x release! But sounds like current trunk can't be anyway. +1 for removing T_VAR and making T_FUNCTION optional in a major release. -1 otherwise. -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
On Thu, Dec 2, 2010 at 14:06, Patrick ALLAERT patrickalla...@php.net wrote: 2010/12/2 André Rømcke a...@ez.no: On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT patrickalla...@php.net wrote: Shouldn't we get rid of that kind of pre-PHP5 stuff _before_ introducing the possible omission of T_FUNCTION? Why? This will break lots of code, does it improve anything while at it? Is 'var' hindering anything? Is it taking up a lot of code? If it is removed then that should be in trunk aka 6.0 the 2nd , and not in 5.x. It should of course not appear in a 5.x release! But sounds like current trunk can't be anyway. +1 for removing T_VAR and making T_FUNCTION optional in a major release. -1 otherwise. -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php An entire major version relied on the usage of T_VAR within classes. Many people still use it today. I therefore am strongly against removing T_VAR, considering it would break huge amounts of userland code. In either case, it should be deprecated with an E_DEPRECATED warning during at least another major before it gets removed. Regards, Peter Beverloo -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
2010/12/2 Peter Beverloo pe...@lvp-media.com: On Thu, Dec 2, 2010 at 14:06, Patrick ALLAERT patrickalla...@php.net wrote: 2010/12/2 André Rømcke a...@ez.no: On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT patrickalla...@php.net wrote: Shouldn't we get rid of that kind of pre-PHP5 stuff _before_ introducing the possible omission of T_FUNCTION? Why? This will break lots of code, does it improve anything while at it? Is 'var' hindering anything? Is it taking up a lot of code? If it is removed then that should be in trunk aka 6.0 the 2nd , and not in 5.x. It should of course not appear in a 5.x release! But sounds like current trunk can't be anyway. +1 for removing T_VAR and making T_FUNCTION optional in a major release. -1 otherwise. -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php An entire major version relied on the usage of T_VAR within classes. Many people still use it today. I therefore am strongly against removing T_VAR, considering it would break huge amounts of userland code. If people migrate to a major version of PHP 5 they should at least stop relying on PHP 4 features still valid thanks to BC consideration. In either case, it should be deprecated with an E_DEPRECATED warning during at least another major before it gets removed. This makes much sense! -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
On 12/2/10 7:51 AM, Patrick ALLAERT wrote: +1 for removing T_VAR and making T_FUNCTION optional in a major release. -1 otherwise. I am still firmly -1 on removing T_FUNCTION for methods. -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php An entire major version relied on the usage of T_VAR within classes. Many people still use it today. I therefore am strongly against removing T_VAR, considering it would break huge amounts of userland code. If people migrate to a major version of PHP 5 they should at least stop relying on PHP 4 features still valid thanks to BC consideration. In either case, it should be deprecated with an E_DEPRECATED warning during at least another major before it gets removed. This makes much sense! Correct me if I'm wrong, but isn't T_VAR on class members already an E_STRICT warning? I thought it was... --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
On Thu, Dec 2, 2010 at 17:07, la...@garfieldtech.com la...@garfieldtech.com wrote: On 12/2/10 7:51 AM, Patrick ALLAERT wrote: +1 for removing T_VAR and making T_FUNCTION optional in a major release. -1 otherwise. I am still firmly -1 on removing T_FUNCTION for methods. -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php An entire major version relied on the usage of T_VAR within classes. Many people still use it today. I therefore am strongly against removing T_VAR, considering it would break huge amounts of userland code. If people migrate to a major version of PHP 5 they should at least stop relying on PHP 4 features still valid thanks to BC consideration. In either case, it should be deprecated with an E_DEPRECATED warning during at least another major before it gets removed. This makes much sense! Correct me if I'm wrong, but isn't T_VAR on class members already an E_STRICT warning? I thought it was... --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php No, the warning was removed in PHP 5.1.3. Regards, Peter Beverloo -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
-1
On 11/27/2010 08:40 PM, 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
johannes
--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
2010/11/27 Johannes Schlüter johan...@schlueters.de
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Considering variables are prefixed and constants don't have visibility
modifiers, functions in classes would still be easily recognizable.
Syntax analyzing IDEs generally don't rely on single keywords and will
be able to adapt a change like this without too much hassle.
On top of that, seeing that functions in classes are generally
referred to as methods, I believe removing the requirement would
improve consistency.
+1 from me.
Kind regards,
Peter Beverloo
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
2010/11/27 Johannes Schlüter johan...@schlueters.de:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
With this patch, something looks inconsistent to me:
Both properties and methods have a visibility
(public|protected|private) and a keyword: var (T_VAR) and function
(T_FUNCTION) respectively.
However private var $foo; generates a fatal error but private
function foo(){} not?
Cheers,
--
Patrick Allaert
---
http://code.google.com/p/peclapm/ - Alternative PHP Monitor
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
Hi
2010/11/30 Patrick ALLAERT patrickalla...@php.net:
With this patch, something looks inconsistent to me:
Both properties and methods have a visibility
(public|protected|private) and a keyword: var (T_VAR) and function
(T_FUNCTION) respectively.
However private var $foo; generates a fatal error but private
function foo(){} not?
The var keyword is an alias of the public keyword for BC with
PHP4. So it would be illogically to declare a property both private
and public at the same time ;-)
--
regards,
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
my +1 for new major version only, btw :) 2010/11/27 Pierre Joye pierre@gmail.com: +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). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
+1 for next major, but not for middle point release. =) 2010/11/29 Pierre Joye pierre@gmail.com: my +1 for new major version only, btw :) 2010/11/27 Pierre Joye pierre@gmail.com: +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). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
On Sun, Nov 28, 2010 at 11:42 AM, Stas Malyshev smalys...@sugarcrm.comwrote: 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. 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
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
On Sun, Nov 28, 2010 at 12:11 PM, Ferenc Kovacs i...@tyrael.hu wrote: On Sun, Nov 28, 2010 at 11:42 AM, Stas Malyshev smalys...@sugarcrm.comwrote: 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. 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
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
On Sun, 28 Nov 2010 10:42:00 -, Stas Malyshev smalys...@sugarcrm.com wrote: 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
Hi Again: On Sat, Nov 27, 2010 at 08:43:40PM -0500, Daniel Convissor wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
Is this going to make it harder for newbies to pick up OOP from a code readability point of view when they look at other people's and framework's code? Also my IDE autocompletes it for me (maybe I'm being lazy here) so I don't see the overhead as being too onerous ( my personal view though) -- James Butler Sent from my iPhone On 28 Nov 2010, at 14:02, Daniel Convissor dani...@analysisandsolutions.com wrote: Hi Again: On Sat, Nov 27, 2010 at 08:43:40PM -0500, Daniel Convissor wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
On Sun, 2010-11-28 at 09:02 -0500, Daniel Convissor wrote: Hi Again: On Sat, Nov 27, 2010 at 08:43:40PM -0500, Daniel Convissor wrote: Not that my vote really counts, but -1. Doing so would eliminate the helpful ability to grep source code for 'function bar'. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
2010/11/27 Johannes Schlüter johan...@schlueters.de: Without T_FUNCTION token. In my opinion an access modifier /public, private protected, static, final) should still be required for keeping readability. As a plea on behalf of maintenance coders dealing with large, messy codebases, please, please don't impact our ability to run 'grep -rs function functionName *', or hit F8, or whatever your IDE's equivalent is. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
From what I understand T_FUNCTION would be optional, rather than removed altogether, is this the case? This would allow those who want to use it the option of using it and would not break existing code. -- Ross Masters r...@php.net http://rossmasters.com/ 2010/11/28 David Otton phpm...@jawbone.freeserve.co.uk 2010/11/27 Johannes Schlüter johan...@schlueters.de: Without T_FUNCTION token. In my opinion an access modifier /public, private protected, static, final) should still be required for keeping readability. As a plea on behalf of maintenance coders dealing with large, messy codebases, please, please don't impact our ability to run 'grep -rs function functionName *', or hit F8, or whatever your IDE's equivalent is. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
2010/11/28 Ross Masters r...@php.net From what I understand T_FUNCTION would be optional, rather than removed altogether, is this the case? This would allow those who want to use it the option of using it and would not break existing code. Yes, exaclty... -- Regards, Felipe Pena
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
On Sat, 27 Nov 2010, Johannes Schlüter wrote: RFC: http://wiki.php.net/rfc/optional-t-function Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff I'm -1 on this one. Besides this being confusing for people who want to run newer code on older PHP versions; this change does nothing but stop you from having to type function. Something that the parser tells you immediately that you have forgotten this. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
On Sun, 28 Nov 2010 14:58:13 -, David Otton phpm...@jawbone.freeserve.co.uk wrote: 2010/11/27 Johannes Schlüter johan...@schlueters.de: Without T_FUNCTION token. In my opinion an access modifier /public, private protected, static, final) should still be required for keeping readability. As a plea on behalf of maintenance coders dealing with large, messy codebases, please, please don't impact our ability to run 'grep -rs function functionName *', or hit F8, or whatever your IDE's equivalent is. IDEs would not be a problem, they would certainly be updated to locate definitions under the new syntax. As to grep, surely you could use another regular expression, perhaps egrep -rs (public|function) functionName or something similar. This seems like a false problem, it's not like it's hard to locate definitions in C or Java codebases... -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
On Sun, 28 Nov 2010, Johannes Schlüter wrote: On Sun, 2010-11-28 at 09:02 -0500, Daniel Convissor wrote: 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. But they understand function. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
Derick Rethans wrote: On Sat, 27 Nov 2010, Johannes Schlüter wrote: RFC: http://wiki.php.net/rfc/optional-t-function Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff I'm -1 on this one. Besides this being confusing for people who want to run newer code on older PHP versions; this change does nothing but stop you from having to type function. Something that the parser tells you immediately that you have forgotten this. cheers, Derick Join me to the list of people which don't like it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
On 28.11.10 16:14, Gustavo Lopes wrote: On Sun, 28 Nov 2010 14:58:13 -, David Otton phpm...@jawbone.freeserve.co.uk wrote: As a plea on behalf of maintenance coders dealing with large, messy codebases, please, please don't impact our ability to run 'grep -rs function functionName *', or hit F8, or whatever your IDE's equivalent is. IDEs would not be a problem, they would certainly be updated to locate definitions under the new syntax. As to grep, surely you could use another regular expression, perhaps egrep -rs (public|function) functionName or something similar. At least one would have to use the following expression: (public|protected|private|final|static|function) functionName - Martin, -1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
-1 The nuisance of updating IDE, search tools etc doesn't outweigh typing 9 characters less imho. On Nov 28, 2010 11:53 PM, Martin Jansen mar...@divbyzero.net wrote:
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
On Sun, Nov 28, 2010 at 10:52 AM, Martin Jansen mar...@divbyzero.netwrote: On 28.11.10 16:14, Gustavo Lopes wrote: On Sun, 28 Nov 2010 14:58:13 -, David Otton phpm...@jawbone.freeserve.co.uk wrote: As a plea on behalf of maintenance coders dealing with large, messy codebases, please, please don't impact our ability to run 'grep -rs function functionName *', or hit F8, or whatever your IDE's equivalent is. IDEs would not be a problem, they would certainly be updated to locate definitions under the new syntax. As to grep, surely you could use another regular expression, perhaps egrep -rs (public|function) functionName or something similar. At least one would have to use the following expression: (public|protected|private|final|static|function) functionName Just to be clear, this works on the assumption that we don't know the class name that the function resides in? I understand the search argument, but to me it only applies to functions, not methods. Is anyone arguing for removing the T_FUNCTION requirement on functions? - Martin, -1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
-1 May harm code portability and maintainability, allows intended or accidental fluctuations in code consistence. On Sun, Nov 28, 2010 at 6:10 PM, Tjerk Meesters tjerk.meest...@gmail.comwrote: -1 The nuisance of updating IDE, search tools etc doesn't outweigh typing 9 characters less imho. On Nov 28, 2010 11:53 PM, Martin Jansen mar...@divbyzero.net wrote:
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
Dallas Gutauckis wrote:
Just to be clear, this works on the assumption that we don't know the class
name that the function resides in?
I understand the search argument, but to me it only applies to functions,
not methods. Is anyone arguing for removing the T_FUNCTION requirement on
functions?
Even knowing the class you are calling, and assuming the common
convention of
one file per class, you may not know in which file is it implemented.
It's annoying
to go into the class, find out it's not there, grep the parent class,
and having to
repeat the process three or four levels up.
Whereas with a unique enough name, grepping the functions get all the
possible
implementations.
Plus, it's not always easy to know in which class to look something :-)
function baz( $param ) {
$param-morlocks();
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
Add my name to the list of people who prefer more strict than syntactic sugar. -1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
2010/11/28 Ángel González keis...@gmail.com
Dallas Gutauckis wrote:
Just to be clear, this works on the assumption that we don't know the
class
name that the function resides in?
I understand the search argument, but to me it only applies to functions,
not methods. Is anyone arguing for removing the T_FUNCTION requirement on
functions?
Even knowing the class you are calling, and assuming the common
convention of
one file per class, you may not know in which file is it implemented.
It's annoying
to go into the class, find out it's not there, grep the parent class,
and having to
repeat the process three or four levels up.
Whereas with a unique enough name, grepping the functions get all the
possible
implementations.
Plus, it's not always easy to know in which class to look something :-)
I understand the concern from above, but I don't agree with it
fundamentally. The kind of practice suggested by this search mechanic tells
me that either there is lack of or little documentation, and lack of or
little understanding of the codebase in which the code resides thereby
making this argument flawed based solely on the assumption that the majority
of code is (or should be) poorly maintained/documented.
Below is simply bad programming practice in many ways. No validation of type
(neither through type-hinting nor an instanceof check) is done, which is why
the code is so difficult to trace back. Presumably, you'd also have some
form of documentation (PHPDoc, anyone?) that would facilitate the search for
the declaration of that function. Again, that assumes a better programming
practice than is being provided as the example below. One would hope that
someone excluding their function keyword would also be up to date enough
to be validating objects.
function baz( $param ) {
$param-morlocks();
}
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
Oh, and I haven't +1 or -1'd.
I write in many languages, some of which don't have method keywords (like
Java: public void doSomething()) and some of which do (like PHP: public
function doSomething()). I trip up whenever I switch between languages, and
it's in both directions.
Ultimately, I feel the keyword is rather useless from a readability
standpoint. The only advantage is for searching (again, moreso on functions
than methods) but still, the argument is there.
2010/11/28 Dallas Gutauckis dal...@gutauckis.com
2010/11/28 Ángel González keis...@gmail.com
Dallas Gutauckis wrote:
Just to be clear, this works on the assumption that we don't know the
class
name that the function resides in?
I understand the search argument, but to me it only applies to
functions,
not methods. Is anyone arguing for removing the T_FUNCTION requirement
on
functions?
Even knowing the class you are calling, and assuming the common
convention of
one file per class, you may not know in which file is it implemented.
It's annoying
to go into the class, find out it's not there, grep the parent class,
and having to
repeat the process three or four levels up.
Whereas with a unique enough name, grepping the functions get all the
possible
implementations.
Plus, it's not always easy to know in which class to look something :-)
I understand the concern from above, but I don't agree with it
fundamentally. The kind of practice suggested by this search mechanic tells
me that either there is lack of or little documentation, and lack of or
little understanding of the codebase in which the code resides thereby
making this argument flawed based solely on the assumption that the majority
of code is (or should be) poorly maintained/documented.
Below is simply bad programming practice in many ways. No validation of
type (neither through type-hinting nor an instanceof check) is done, which
is why the code is so difficult to trace back. Presumably, you'd also have
some form of documentation (PHPDoc, anyone?) that would facilitate the
search for the declaration of that function. Again, that assumes a better
programming practice than is being provided as the example below. One would
hope that someone excluding their function keyword would also be up to
date enough to be validating objects.
function baz( $param ) {
$param-morlocks();
}
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
Ángel González wrote: Derick Rethans wrote: On Sat, 27 Nov 2010, Johannes Schlüter wrote: RFC: http://wiki.php.net/rfc/optional-t-function Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff I'm -1 on this one. Besides this being confusing for people who want to run newer code on older PHP versions; this change does nothing but stop you from having to type function. Something that the parser tells you immediately that you have forgotten this. Join me to the list of people which don't like it. And since my name has already been mentioned ;) I see little point in removing what is a very useful 'flag' when trying to understand other peoples code. Yes PHPEclipse will take me to the right definition ( and does all the type hinting that I need! ) but this is still a useful hook when managing code? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
On Sunday, November 28, 2010 9:12:34 am Felipe Pena wrote: 2010/11/28 Ross Masters r...@php.net From what I understand T_FUNCTION would be optional, rather than removed altogether, is this the case? This would allow those who want to use it the option of using it and would not break existing code. Yes, exaclty... File me -1. The above argument is oft-used but is not, in fact, a valid argument unless all of the code you work with is your own. The minute you start using 3rd party code (you know, sharing generic libraries in good software engineering and open source etiquette) you are at the whim of whatever syntactic options they chose to use. Optional function, strict typing, exceptions, the list goes on. There is no such thing as an optional language feature if you're working with code you didn't write. Given that, making functional optional makes the language more complex (for me visually scanning it, for an IDE parsing it, etc.) in order to save a few characters. Bad trade-off. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
On Sunday, November 28, 2010 11:24:02 am Dallas Gutauckis wrote:
I understand the concern from above, but I don't agree with it
fundamentally. The kind of practice suggested by this search mechanic tells
me that either there is lack of or little documentation, and lack of or
little understanding of the codebase in which the code resides thereby
making this argument flawed based solely on the assumption that the
majority of code is (or should be) poorly maintained/documented.
Below is simply bad programming practice in many ways. No validation of
type (neither through type-hinting nor an instanceof check) is done, which
is why the code is so difficult to trace back. Presumably, you'd also have
some form of documentation (PHPDoc, anyone?) that would facilitate the
search for the declaration of that function. Again, that assumes a better
programming practice than is being provided as the example below. One
would hope that someone excluding their function keyword would also be up
to date enough to be validating objects.
function baz( $param ) {
$param-morlocks();
}
I would like to know how to get to the fantasy world you describe in which all
developers are doing careful type checking and proper DocBlocks on everything.
It sounds like it would be a glorious place to live, if only it could exist.
(I routinely beat people over the head about that in a project with very good
documentation standards, and we still have extremely good developers writing
code that fails both of the above.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
2010/11/28 Dallas Gutauckis dal...@gutauckis.com: I understand the concern from above, but I don't agree with it fundamentally. The kind of practice suggested by this search mechanic tells me that either there is lack of or little documentation, and lack of or little understanding of the codebase in which the code resides thereby making this argument flawed based solely on the assumption that the majority of code is (or should be) poorly maintained/documented. Yes. Absolutely. The majority of code /is/ poorly maintained and documented. I work with scrappy codebases that have seen dozens of devs over their lifetimes, and this patch removes one of the few certainties - that 'grep function X' is absolutely the fastest way to find the place where X is declared. I'm not an internals guy, so I can't vote, but I will ask you to reconsider this one. 2010/11/28 Ross Masters r...@php.net: From what I understand T_FUNCTION would be optional, rather than removed altogether, is this the case? This would allow those who want to use it the option of using it and would not break existing code. My worry is that the last-guy-but-five used the new syntax and now I have to apply a fix to his code. Yeah, I'll find the function on my second/third attempt, but it is an impediment. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
2010/11/28 Johannes Schlüter johan...@schlueters.de: Without T_FUNCTION token. In my opinion an access modifier /public, private protected, static, final) should still be required for keeping readability. I'd be -1 at the moment. The patch is certainly fine, but I think this has the potential to generate a lot of head-scratchers for neophyte coders trying to support code across multiple versions, and would increase our support burden for the benefit of removing a few keystrokes that every remotely experienced PHP developer already has committed to muscle memory. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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 BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
2010/11/27 Johannes Schlüter johan...@schlueters.de: 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 ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
2010/11/27 Johannes Schlüter johan...@schlueters.de 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
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
As long as a modifier (public|private|protected) is still required, +1.
2010/11/27 Johannes Schlüter johan...@schlueters.de:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
+1
2010/11/27 Johannes Schlüter johan...@schlueters.de
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
+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 pierr...@webstart.fr:
+1
2010/11/27 Johannes Schlüter johan...@schlueters.de
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
On Sat, 2010-11-27 at 19:30 +0100, Pierre Joye wrote: +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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
+1 to being able to omit the function keyword.
2010/11/27 Johannes Schlüter johan...@schlueters.de:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
2010/11/27 Philip Olson phi...@roshambo.org 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php 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
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
2010/11/27 Johannes Schlüter johan...@schlueters.de
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
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
+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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
On 27 nov 2010, at 18:40, Johannes Schlüter johan...@schlueters.de
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
On Sat, 2010-11-27 at 22:58 +0100, Mike Van Riel wrote:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
On Sat, 2010-11-27 at 23:14 +0100, Johannes Schlüter wrote:
[ T_PUBLIC | T_PROTECTED | T_PRIVATE | T_STATIC | T_ABSTRACT ] { } T_STRING
( param_list ) { { statement_ist } }
I forgot T_FINAL there.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
@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 johan...@schlueters.de
On Sat, 2010-11-27 at 23:14 +0100, Johannes Schlüter wrote:
[ T_PUBLIC | T_PROTECTED | T_PRIVATE | T_STATIC | T_ABSTRACT ] { }
T_STRING ( param_list ) { { statement_ist } }
I forgot T_FINAL there.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
Hi:
On Sat, Nov 27, 2010 at 06:40:23PM +0100, Johannes Schlter wrote:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
