FAQ
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

Search Discussions

  • Sebastian Bergmann at Nov 27, 2010 at 5:50 pm

    +1

    --
    Sebastian Bergmann Co-Founder and Principal Consultant
    http://sebastian-bergmann.de/ http://thePHP.cc/
  • Kalle Sommer Nielsen at Nov 27, 2010 at 5:52 pm

    +1, I've missed being able to skip the function keyword for a while now.


    --
    regards,

    Kalle Sommer Nielsen
    kalle@php.net
  • Felipe Pena at Nov 27, 2010 at 5:53 pm
    2010/11/27 Johannes Schlüter <johannes@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
  • Ilia Alshanetsky at Nov 27, 2010 at 5:54 pm
    As long as a modifier (public|private|protected) is still required, +1.

    2010/11/27 Johannes Schlüter <johannes@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
  • Pierrick Charron at Nov 27, 2010 at 5:56 pm
    +1

    2010/11/27 Johannes Schlüter <johannes@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 Joye at Nov 27, 2010 at 6:30 pm
    +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 <pierrick@webstart.fr>:
    +1

    2010/11/27 Johannes Schlüter <johannes@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
  • Johannes Schlüter at Nov 27, 2010 at 6:41 pm

    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
  • Pierre Joye at Nov 29, 2010 at 12:22 pm
    my +1 for new major version only, btw :)

    2010/11/27 Pierre Joye <pierre.php@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,
  • Guilhermeblanco at Nov 29, 2010 at 5:26 pm
    +1 for next major, but not for middle point release. =)

    2010/11/29 Pierre Joye <pierre.php@gmail.com>:
    my +1 for new major version only, btw :)

    2010/11/27 Pierre Joye <pierre.php@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: guilhermeblanco@hotmail.com
    São Paulo - SP/Brazil
  • Ross Masters at Nov 27, 2010 at 6:35 pm
    +1, has crossed my mind before =)

    "Johannes "Schlüter"" wrote in message
    news:1290879624.7033.826.camel@guybrush...

    Hi,

    every now and then while writing classes I forget to add the "function"
    keyword between my visibility modifier and the method name in a class
    declaration. I don't think it is required for readability and it is not
    needed by the parser to prevent conflicts, I therefore propose the
    following RFC incl. patch to allow writing

    class Foo {
    public bar() {
    echo "Hello World";
    }
    }

    Without T_FUNCTION token. In my opinion an access modifier /public,
    private protected, static, final) should still be required for keeping
    readability.

    RFC: http://wiki.php.net/rfc/optional-t-function
    Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff

    johannes
  • Philip Olson at Nov 27, 2010 at 6:46 pm
    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
  • Ferenc Kovacs at Nov 27, 2010 at 9:05 pm
    2010/11/27 Philip Olson <philip@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
  • Stas Malyshev at Nov 28, 2010 at 10:42 am
    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
  • Ferenc Kovacs at Nov 28, 2010 at 11:11 am

    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
  • Ferenc Kovacs at Nov 28, 2010 at 11:11 am
    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
  • Gustavo Lopes at Nov 28, 2010 at 11:18 am

    On Sun, 28 Nov 2010 10:42:00 -0000, 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
  • Marcello Duarte at Nov 27, 2010 at 8:33 pm
    +1 to being able to omit the function keyword.

    2010/11/27 Johannes Schlüter <johannes@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
  • Ferenc Kovacs at Nov 27, 2010 at 9:10 pm
    2010/11/27 Johannes Schlüter <johannes@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
  • Jani Taskinen at Nov 27, 2010 at 9:23 pm
    +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

  • Mike Van Riel at Nov 27, 2010 at 9:58 pm

    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
  • Johannes Schlüter at Nov 27, 2010 at 10:14 pm

    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
  • Johannes Schlüter at Nov 27, 2010 at 10:21 pm

    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
  • Martin Wernstahl at Nov 27, 2010 at 11:13 pm
    @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 <johannes@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
  • Daniel Convissor at Nov 28, 2010 at 1:43 am
    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
  • Daniel Convissor at Nov 28, 2010 at 2:02 pm
    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
  • Johannes Schlüter at Nov 28, 2010 at 2:30 pm

    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
  • Derick Rethans at Nov 28, 2010 at 3:18 pm

    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
  • James Butler at Nov 28, 2010 at 2:29 pm
    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
  • David Otton at Nov 28, 2010 at 2:58 pm

    2010/11/27 Johannes Schlüter <johannes@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.
  • Ross Masters at Nov 28, 2010 at 3:04 pm
    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 <ross@php.net>
    http://rossmasters.com/



    2010/11/28 David Otton <phpmail@jawbone.freeserve.co.uk>
    2010/11/27 Johannes Schlüter <johannes@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
  • Felipe Pena at Nov 28, 2010 at 3:12 pm
    2010/11/28 Ross Masters <ross@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
  • Larry Garfield at Nov 28, 2010 at 9:04 pm

    On Sunday, November 28, 2010 9:12:34 am Felipe Pena wrote:
    2010/11/28 Ross Masters <ross@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
  • Gustavo Lopes at Nov 28, 2010 at 3:17 pm

    On Sun, 28 Nov 2010 14:58:13 -0000, David Otton wrote:

    2010/11/27 Johannes Schlüter <johannes@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
  • Martin Jansen at Nov 28, 2010 at 3:52 pm

    On 28.11.10 16:14, Gustavo Lopes wrote:
    On Sun, 28 Nov 2010 14:58:13 -0000, 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
  • Tjerk Meesters at Nov 28, 2010 at 4:10 pm
    -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:
  • Seva Lapsha at Nov 28, 2010 at 4:14 pm
    -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:
  • Stanley Sufficool at Nov 28, 2010 at 5:17 pm
    Add my name to the list of people who prefer more strict than syntactic sugar.

    -1
  • Dallas Gutauckis at Nov 28, 2010 at 4:12 pm

    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 -0000, 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
  • Ángel González at Nov 28, 2010 at 5:15 pm

    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();
    }
  • Dallas Gutauckis at Nov 28, 2010 at 5:24 pm
    2010/11/28 Ángel González <keisial@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();
    }
  • Dallas Gutauckis at Nov 28, 2010 at 5:29 pm
    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 <dallas@gutauckis.com>

    2010/11/28 Ángel González <keisial@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();
    }
  • Larry Garfield at Nov 28, 2010 at 9:09 pm

    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
  • David Otton at Nov 28, 2010 at 10:51 pm

    2010/11/28 Dallas Gutauckis <dallas@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 <ross@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.
  • Derick Rethans at Nov 28, 2010 at 3:14 pm

    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
  • Ángel González at Nov 28, 2010 at 3:48 pm

    Derick Rethans wrote:
    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.
  • Lester Caine at Nov 28, 2010 at 8:23 pm

    Ángel González wrote:
    Derick Rethans wrote:
    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
  • Adam Harvey at Nov 29, 2010 at 3:32 am

    2010/11/28 Johannes Schlüter <johannes@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
  • Michael Wallner at Nov 30, 2010 at 8:52 am

    On 11/27/2010 06:40 PM, Johannes Schlüter wrote:
    Hi, ...
    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 for any PHP version. Insisting on keeping T_FUNCTION means advocating
    PHP to stay the odd anomaly in programming languages to me.

    Regards,
    Mike
  • Arvids Godjuks at Nov 30, 2010 at 9:24 am
    Personally, as a user-land developer, I'm against it, so -1.
    function keyword is the only sane way to quickly find a function
    definition in lots of code. Not always IDE's are able to fully
    understand the interconnections in frameworks and point by CTRL +
    Click me to the function definition, not to say that in many cases you
    just don't have that IDE available right now and right here.
    Now it's quite easy to make a search on a folder recursively - just
    enter "function blah" and here you go - one entry with the function
    definition. Try that with the function/method name without the
    "function" keyword, good luck with going through tons of entries.

    I deal with typing the whole "public/private function blabla() {" by
    defining a auto complete shortcut like "prfnc => space => private
    function |(){" where | is cursor.

    Please keep it KISS way. Language should evolve for sure, but some
    things are not just worth sacrificing the verbosity even if it means
    cuts typing some of the most common keywords in the language and can
    be perfectly done keeping the BC.

    P.S. Personally I will prohibit my developers to use the short syntax
    without the "function" keyword.
  • Gwynne Raskind at Nov 30, 2010 at 9:49 am

    On Nov 30, 2010, at 4:24 AM, Arvids Godjuks wrote:
    Personally, as a user-land developer, I'm against it, so -1.
    function keyword is the only sane way to quickly find a function
    definition in lots of code. Not always IDE's are able to fully
    understand the interconnections in frameworks and point by CTRL +
    Click me to the function definition, not to say that in many cases you
    just don't have that IDE available right now and right here.
    Now it's quite easy to make a search on a folder recursively - just
    enter "function blah" and here you go - one entry with the function
    definition. Try that with the function/method name without the
    "function" keyword, good luck with going through tons of entries.

    I deal with typing the whole "public/private function blabla() {" by
    defining a auto complete shortcut like "prfnc => space => private
    function |(){" where | is cursor.

    Please keep it KISS way. Language should evolve for sure, but some
    things are not just worth sacrificing the verbosity even if it means
    cuts typing some of the most common keywords in the language and can
    be perfectly done keeping the BC.

    P.S. Personally I will prohibit my developers to use the short syntax
    without the "function" keyword.
    Agreed. -1 here also.

    -- Gwynne

Related Discussions

People

Translate

site design / logo © 2022 Grokbase