FAQ
Hi,

I have started the vote for extended keyword support RFC:

https://wiki.php.net/rfc/keywords_as_identifiers

Deadline is Monday, next week (28.10.2013)

Bob Weinand

Search Discussions

  • Derick Rethans at Oct 22, 2013 at 9:11 am

    On Mon, 21 Oct 2013, Bob Weinand wrote:

    I have started the vote for extended keyword support RFC:

    https://wiki.php.net/rfc/keywords_as_identifiers
    Just to explain why I voted "no". I think the idea is good, but what I
    see from the patch is that it adds a *lot* of hand written state
    machines which are going to be a pain to maintain. I do not think this
    extra maintenance is worth the features - we've done pretty well without
    it.

    cheers,
    Derick
  • Pierre Joye at Oct 22, 2013 at 9:30 am

    On Tue, Oct 22, 2013 at 11:11 AM, Derick Rethans wrote:
    On Mon, 21 Oct 2013, Bob Weinand wrote:

    I have started the vote for extended keyword support RFC:

    https://wiki.php.net/rfc/keywords_as_identifiers
    Just to explain why I voted "no". I think the idea is good, but what I
    see from the patch is that it adds a *lot* of hand written state
    machines which are going to be a pain to maintain. I do not think this
    extra maintenance is worth the features - we've done pretty well without
    it.
    I did not vote yet, however I agree with Derick. A cleaner solution
    would be better. We have lived with this restriction for some time
    already and we may as well delay this RFC until we have a viable
    technical solution. If anyone feels motivated enough to implement the
    parser/lexer using other tools :)


    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Bob Weinand at Oct 22, 2013 at 9:52 am

    Am 22.10.2013 um 11:30 schrieb Pierre Joye <pierre.php@gmail.com>:
    On Tue, Oct 22, 2013 at 11:11 AM, Derick Rethans wrote:
    On Mon, 21 Oct 2013, Bob Weinand wrote:
    I have started the vote for extended keyword support RFC:

    https://wiki.php.net/rfc/keywords_as_identifiers
    Just to explain why I voted "no". I think the idea is good, but what I
    see from the patch is that it adds a *lot* of hand written state
    machines which are going to be a pain to maintain. I do not think this
    extra maintenance is worth the features - we've done pretty well without
    it.
    I did not vote yet, however I agree with Derick. A cleaner solution
    would be better. We have lived with this restriction for some time
    already and we may as well delay this RFC until we have a viable
    technical solution. If anyone feels motivated enough to implement the
    parser/lexer using other tools :)


    --
    Pierre

    @pierrejoye | http://www.libgd.org
    Thank you for the feedback,

    I actually don't think that it would be hard to maintain as it still is only a
    limited set of keywords where extra conditions are necessary.

    You rarely should have to change the implementation.

    If anyone has an idea how I could just write in the parser:

    "T_STRING or (alphabetic keyword with lowest precedence)"

    then that'd be very welcome, but I didn't actually find a solution for that
    without a lot of reduce/reduce conflicts.

    See also that initial implementation which just involved parser,
    but had more limited keyword support:
    https://github.com/bwoebi/php-src/commit/18c78af2d9ff27cf2df3ad0e63f5c4cce11a5db3

    Bob Weinand
  • Sebastian Bergmann at Oct 22, 2013 at 9:53 am

    On 10/22/2013 11:30 AM, Pierre Joye wrote:
    I did not vote yet, however I agree with Derick. A cleaner solution
    would be better. We have lived with this restriction for some time
    already and we may as well delay this RFC until we have a viable
    technical solution. If anyone feels motivated enough to implement the
    parser/lexer using other tools :)
      The implementation has to be clean and the experience to users has
      to be consistent. Last time I looked at the RFC the implementation
      only allowed some keywords to be used in some contexts where keywords
      could not be used previously. Not allowing all keywords in all contexts
      only leads to confusion.
  • Bob Weinand at Oct 22, 2013 at 10:07 am

    Am 22.10.2013 um 11:53 schrieb Sebastian Bergmann <sebastian@php.net>:
    On 10/22/2013 11:30 AM, Pierre Joye wrote:
    I did not vote yet, however I agree with Derick. A cleaner solution
    would be better. We have lived with this restriction for some time
    already and we may as well delay this RFC until we have a viable
    technical solution. If anyone feels motivated enough to implement the
    parser/lexer using other tools :)
    The implementation has to be clean and the experience to users has
    to be consistent. Last time I looked at the RFC the implementation
    only allowed some keywords to be used in some contexts where keywords
    could not be used previously. Not allowing all keywords in all contexts
    only leads to confusion.
    I had announced previously on the list and it's noted in the RFC too, that
    these inconsistencies had been removed.

    That's actually not the problem; Pierre and Derick are talking about the
    implementation in C.

    Bob Weinand
  • Sebastian Bergmann at Oct 22, 2013 at 10:10 am

    On 10/22/2013 12:08 PM, Bob Weinand wrote:
    I had announced previously on the list and it's noted in the RFC too, that
    these inconsistencies had been removed.
      Okay, thanks for the information.
    That's actually not the problem; Pierre and Derick are talking about the
    implementation in C.
      I understood the point Pierre and Derick raised.
  • Etienne Kneuss at Oct 22, 2013 at 10:25 am
    Hi,

    IMHO lifting this "keyword <> identifiers" restriction is a good idea. I'm
    not sure that it is worth replacing our current keywords though.

    However, I think it is a very good solution for future language constructs
    that want to keep BC. So we should at least keep it in mind in case it is
    rejected.

    Best,
  • Zeev Suraski at Oct 22, 2013 at 10:54 am

    -----Original Message-----
    From: Derick Rethans
    Sent: Tuesday, October 22, 2013 12:12 PM
    To: Bob Weinand
    Cc: Developers Mailing List PHP
    Subject: Re: [PHP-DEV] [RFC] [Vote] Keywords as identifiers
    On Mon, 21 Oct 2013, Bob Weinand wrote:

    I have started the vote for extended keyword support RFC:

    https://wiki.php.net/rfc/keywords_as_identifiers
    Just to explain why I voted "no". I think the idea is good, but what I see from
    the patch is that it adds a *lot* of hand written state machines which are
    going to be a pain to maintain. I do not think this extra maintenance is worth
    the features - we've done pretty well without it.
    Thumbs up for the idea as well, but I don't think we can live with the
    implementation. BTW, that's a bit of a grey area but I think that even if
    an idea is accepted, if there's no reasonably clean implementation
    available for it, I don't think it can go in.

    Zeev
  • Bob Weinand at Oct 22, 2013 at 11:01 am

    Am 22.10.2013 um 12:54 schrieb "Zeev Suraski" <zeev@zend.com>:
    -----Original Message-----
    From: Derick Rethans
    Sent: Tuesday, October 22, 2013 12:12 PM
    To: Bob Weinand
    Cc: Developers Mailing List PHP
    Subject: Re: [PHP-DEV] [RFC] [Vote] Keywords as identifiers
    On Mon, 21 Oct 2013, Bob Weinand wrote:

    I have started the vote for extended keyword support RFC:

    https://wiki.php.net/rfc/keywords_as_identifiers
    Just to explain why I voted "no". I think the idea is good, but what I see from
    the patch is that it adds a *lot* of hand written state machines which are
    going to be a pain to maintain. I do not think this extra maintenance is worth
    the features - we've done pretty well without it.
    Thumbs up for the idea as well, but I don't think we can live with the
    implementation. BTW, that's a bit of a grey area but I think that even if
    an idea is accepted, if there's no reasonably clean implementation
    available for it, I don't think it can go in.

    Zeev
    As said, if anyone has a good idea how to improve the implementation, I'd be happy to implement it.

    (I really can't imagine a better way...)

    Bob Weinand

    (Btw. Is my implementation so bad? I think it looks far worse than it is in reality...)
  • Derick Rethans at Oct 22, 2013 at 12:28 pm

    On Tue, 22 Oct 2013, Bob Weinand wrote:

    Am 22.10.2013 um 12:54 schrieb "Zeev Suraski" <zeev@zend.com>:
    From: Derick Rethans
    Sent: Tuesday, October 22, 2013 12:12 PM
    On Mon, 21 Oct 2013, Bob Weinand wrote:

    I have started the vote for extended keyword support RFC:

    https://wiki.php.net/rfc/keywords_as_identifiers
    Just to explain why I voted "no". I think the idea is good, but
    what I see from the patch is that it adds a *lot* of hand written
    state machines which are going to be a pain to maintain. I do not
    think this extra maintenance is worth the features - we've done
    pretty well without it.
    Thumbs up for the idea as well, but I don't think we can live with
    the implementation. BTW, that's a bit of a grey area but I think
    that even if an idea is accepted, if there's no reasonably clean
    implementation available for it, I don't think it can go in.
    As said, if anyone has a good idea how to improve the implementation,
    I'd be happy to implement it.
    That's not an excuse for adding code that people disagree with.
    Btw. Is my implementation so bad? I think it looks far worse than it
    is in reality...)
    You add 350 lines of almost-hand-crafted parsing to the lexer, which I
    consider "modereately bad". My point is that I don't think it's worth
    this extra complication for a "not really important" feature.

    cheers,
    Derick

    --
    http://derickrethans.nl | http://xdebug.org
    Like Xdebug? Consider a donation: http://xdebug.org/donate.php
    twitter: @derickr and @xdebug
    Posted with an email client that doesn't mangle email: alpine
  • Bob Weinand at Oct 22, 2013 at 12:55 pm

    Am 22.10.2013 um 14:28 schrieb Derick Rethans <derick@php.net>:
    On Tue, 22 Oct 2013, Bob Weinand wrote:
    Am 22.10.2013 um 12:54 schrieb "Zeev Suraski" <zeev@zend.com>:
    From: Derick Rethans
    Sent: Tuesday, October 22, 2013 12:12 PM
    On Mon, 21 Oct 2013, Bob Weinand wrote:

    I have started the vote for extended keyword support RFC:

    https://wiki.php.net/rfc/keywords_as_identifiers
    Just to explain why I voted "no". I think the idea is good, but
    what I see from the patch is that it adds a *lot* of hand written
    state machines which are going to be a pain to maintain. I do not
    think this extra maintenance is worth the features - we've done
    pretty well without it.
    Thumbs up for the idea as well, but I don't think we can live with
    the implementation. BTW, that's a bit of a grey area but I think
    that even if an idea is accepted, if there's no reasonably clean
    implementation available for it, I don't think it can go in.
    As said, if anyone has a good idea how to improve the implementation,
    I'd be happy to implement it.
    That's not an excuse for adding code that people disagree with.
    I agree, but if people disagree, then I'd like to hear which code they'd prefer.
    Btw. Is my implementation so bad? I think it looks far worse than it
    is in reality...)
    You add 350 lines of almost-hand-crafted parsing to the lexer, which I
    consider "modereately bad". My point is that I don't think it's worth
    this extra complication for a "not really important" feature.

    About 150 lines parsing, the other are macros and other logic.

    Actually syntax is mostly:
    if (buf_one_token == T_TOKEN && LEX_IS_CUR_ALPH_TOKEN()) {
         LEX_CONVERT_CUR_STRING();
    }

    That's not much more complicated than just writing something like:

    T_TOKEN ALPH_TOKEN {
         LEX_CONVERT_CUR_STRING();
    }

    in a bison/yacc parser.

    ___

    Also, it is not a really complication; it's just a transparent additional step
    you usually don't have to modify and could even remove without loosing
    any features except the keyword support.

    Bob Weinand
  • Zeev Suraski at Oct 22, 2013 at 8:40 pm

    Thumbs up for the idea as well, but I don't think we can live with the
    implementation. BTW, that's a bit of a grey area but I think that
    even if an idea is accepted, if there's no reasonably clean
    implementation available for it, I don't think it can go in.

    Zeev
    As said, if anyone has a good idea how to improve the implementation, I'd
    be happy to implement it.

    (I really can't imagine a better way...)
    I think the point that Derick is trying to make, and that I agree with -
    is that if there's no better way to implement it we shouldn't be
    implementing it at all. In other words, coming up with a clean
    implementation is a requirement before we can go ahead and introduce this
    feature into the language. I did not mean to imply you did a poor job
    implementing it, I don't presently have an idea of how to make it better.

    Zeev
  • Julien Pauli at Oct 24, 2013 at 1:44 pm

    On Tue, Oct 22, 2013 at 10:40 PM, Zeev Suraski wrote:

    Thumbs up for the idea as well, but I don't think we can live with the
    implementation. BTW, that's a bit of a grey area but I think that
    even if an idea is accepted, if there's no reasonably clean
    implementation available for it, I don't think it can go in.

    Zeev
    As said, if anyone has a good idea how to improve the implementation, I'd
    be happy to implement it.

    (I really can't imagine a better way...)
    I think the point that Derick is trying to make, and that I agree with -
    is that if there's no better way to implement it we shouldn't be
    implementing it at all. In other words, coming up with a clean
    implementation is a requirement before we can go ahead and introduce this
    feature into the language. I did not mean to imply you did a poor job
    implementing it, I don't presently have an idea of how to make it better.
    I'm all +1 with that.

    Don't forget that we have been leaving with those reserved keyword for ~15y
    now, and just right.
    I don't think we should hurry on such a feature adding so much complicated
    stuff, especially to the lexer.

    Julien.Pauli
  • Kevin Ingwersen at Oct 24, 2013 at 2:35 pm
    Hello there! I just recently joined the mailing list - what is this vote about?
    Kind regards, Kevin Ingwersen
    Am 24.10.2013 um 15:37 schrieb Julien Pauli <jpauli@php.net>:
    On Tue, Oct 22, 2013 at 10:40 PM, Zeev Suraski wrote:

    Thumbs up for the idea as well, but I don't think we can live with the
    implementation. BTW, that's a bit of a grey area but I think that
    even if an idea is accepted, if there's no reasonably clean
    implementation available for it, I don't think it can go in.

    Zeev
    As said, if anyone has a good idea how to improve the implementation, I'd
    be happy to implement it.

    (I really can't imagine a better way...)
    I think the point that Derick is trying to make, and that I agree with -
    is that if there's no better way to implement it we shouldn't be
    implementing it at all. In other words, coming up with a clean
    implementation is a requirement before we can go ahead and introduce this
    feature into the language. I did not mean to imply you did a poor job
    implementing it, I don't presently have an idea of how to make it better.
    I'm all +1 with that.

    Don't forget that we have been leaving with those reserved keyword for ~15y
    now, and just right.
    I don't think we should hurry on such a feature adding so much complicated
    stuff, especially to the lexer.

    Julien.Pauli
  • Stas Malyshev at Oct 22, 2013 at 8:35 pm
    Hi!
    Just to explain why I voted "no". I think the idea is good, but what I
    see from the patch is that it adds a *lot* of hand written state
    machines which are going to be a pain to maintain. I do not think this
    extra maintenance is worth the features - we've done pretty well without
    it.
    Exactly the same here. I love the idea, but looking at the code I
    realize even with my experience about what's going on in the engine I
    have hard time understanding what's going on there, and we're not
    talking about some obscure nook of the engine - parser is right in the
    middle of everything. So I personally adding so much complexity is not
    worth the cost. If we can find a solution to do the same (or roughly the
    same, sacrificing some less important features) without adding so much
    complexity it'd be much better I think.
    Maybe if you made a good narrative explanation what's going on in that
    code and it turned out it's not as bad as it looks and we just didn't
    realize it, it would be more acceptable.
    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Clint Priest at Oct 23, 2013 at 12:20 am
    I just wanted to +1 for the idea but agree with Stas, Derrick and Zeev
    on the implementation, a simpler way needs to be found to solve the problem.
    On 10/22/2013 3:35 PM, Stas Malyshev wrote:
    Hi!
    Just to explain why I voted "no". I think the idea is good, but what I
    see from the patch is that it adds a *lot* of hand written state
    machines which are going to be a pain to maintain. I do not think this
    extra maintenance is worth the features - we've done pretty well without
    it.
    Exactly the same here. I love the idea, but looking at the code I
    realize even with my experience about what's going on in the engine I
    have hard time understanding what's going on there, and we're not
    talking about some obscure nook of the engine - parser is right in the
    middle of everything. So I personally adding so much complexity is not
    worth the cost. If we can find a solution to do the same (or roughly the
    same, sacrificing some less important features) without adding so much
    complexity it'd be much better I think.
    Maybe if you made a good narrative explanation what's going on in that
    code and it turned out it's not as bad as it looks and we just didn't
    realize it, it would be more acceptable.
  • Guilhermeblanco at Oct 23, 2013 at 4:39 am
    +1 on idea
    -1 on implementation

    On Tue, Oct 22, 2013 at 8:19 PM, Clint Priest wrote:

    I just wanted to +1 for the idea but agree with Stas, Derrick and Zeev on
    the implementation, a simpler way needs to be found to solve the problem.

    On 10/22/2013 3:35 PM, Stas Malyshev wrote:

    Hi!

    Just to explain why I voted "no". I think the idea is good, but what I
    see from the patch is that it adds a *lot* of hand written state
    machines which are going to be a pain to maintain. I do not think this
    extra maintenance is worth the features - we've done pretty well without
    it.
    Exactly the same here. I love the idea, but looking at the code I
    realize even with my experience about what's going on in the engine I
    have hard time understanding what's going on there, and we're not
    talking about some obscure nook of the engine - parser is right in the
    middle of everything. So I personally adding so much complexity is not
    worth the cost. If we can find a solution to do the same (or roughly the
    same, sacrificing some less important features) without adding so much
    complexity it'd be much better I think.
    Maybe if you made a good narrative explanation what's going on in that
    code and it turned out it's not as bad as it looks and we just didn't
    realize it, it would be more acceptable.

    --
    Guilherme Blanco
    MSN: guilhermeblanco@hotmail.com
    GTalk: guilhermeblanco
    Toronto - ON/Canada

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedOct 21, '13 at 2:32p
activeOct 24, '13 at 2:35p
posts18
users11
websitephp.net

People

Translate

site design / logo © 2022 Grokbase