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 : > 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 > 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 :
> 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
> 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 :
> +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
>>
>>
>>
>> --
>> 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 :
> 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 > 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
> 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
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
> 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
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 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. > > 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 wrote: > > > 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 >>> 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 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" 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 : > 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 http://rossmasters.com/ 2010/11/28 David Otton > 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. > > 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 > 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 wrote: 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. 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 > 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" wrote:
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
On Sun, Nov 28, 2010 at 10:52 AM, Martin Jansen wrote: > On 28.11.10 16:14, Gustavo Lopes wrote: > > On Sun, 28 Nov 2010 14:58:13 -, David Otton > > 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 wrote: > -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" 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
> 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
>
>
> 2010/11/28 Ángel González
>
> 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 > > > 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 : > 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 : > 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 : > 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
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
my +1 for new major version only, btw :) 2010/11/27 Pierre Joye : > +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 : > my +1 for new major version only, btw :) > > 2010/11/27 Pierre Joye : >> +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
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
>
>
>
> --
> 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 :
> 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 :
> 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
Hi, first time on the lists, guess I'm from userlando too,
+1 for readability, all I ever really look at are "( ... ){" at the end of
the line so I personally don't think it affects readability. Also, this is
the way its done in other languages and I have always found the function
keyword unnecessary in PHP.
Regards,
David
2010/11/30 Kalle Sommer Nielsen
> Hi
>
> 2010/11/30 Patrick ALLAERT :
> > 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
2010/11/30 Kalle Sommer Nielsen :
> Hi
>
> 2010/11/30 Patrick ALLAERT :
>> 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 wrote:
> 2010/11/30 Kalle Sommer Nielsen :
> > Hi
> >
> > 2010/11/30 Patrick ALLAERT :
> >> 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 wrote:
> 2010/11/30 Kalle Sommer Nielsen :
> > Hi
> >
> > 2010/11/30 Patrick ALLAERT :
> >> 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 wrote:
> On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT >wrote:
>
> > 2010/11/30 Kalle Sommer Nielsen :
> > > Hi
> > >
> > > 2010/11/30 Patrick ALLAERT :
> > >> 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 : > On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT > 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 wrote: > 2010/12/2 André Rømcke : >> On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT >> 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 : > On Thu, Dec 2, 2010 at 14:06, Patrick ALLAERT wrote: >> 2010/12/2 André Rømcke : >>> On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT >>> 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 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
