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
I have started the vote for extended keyword support RFC:
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
I have started the vote for extended keyword support RFC:
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
Am 22.10.2013 um 11:30 schrieb Pierre Joye pierre.php@gmail.com:
I have started the vote for extended keyword support RFC:
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
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.
Am 22.10.2013 um 11:53 schrieb Sebastian Bergmann sebastian@php.net:
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
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.
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,
-----Original Message-----
From: Derick Rethans [mailto:derick@php.net]
Sent: Tuesday, October 22, 2013 12:12 PM
To: Bob Weinand
Cc: Developers Mailing List PHP
Subject: Re: [PHP-DEV] [RFC] [Vote] Keywords as identifiersI have started the vote for extended keyword support RFC:
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
Am 22.10.2013 um 12:54 schrieb "Zeev Suraski" zeev@zend.com:
-----Original Message-----
From: Derick Rethans [mailto:derick@php.net]
Sent: Tuesday, October 22, 2013 12:12 PM
To: Bob Weinand
Cc: Developers Mailing List PHP
Subject: Re: [PHP-DEV] [RFC] [Vote] Keywords as identifiersI have started the vote for extended keyword support RFC:
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...)
Am 22.10.2013 um 12:54 schrieb "Zeev Suraski" zeev@zend.com:
From: Derick Rethans [mailto:derick@php.net]
Sent: Tuesday, October 22, 2013 12:12 PMI have started the vote for extended keyword support RFC:
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
Am 22.10.2013 um 14:28 schrieb Derick Rethans derick@php.net:
Am 22.10.2013 um 12:54 schrieb "Zeev Suraski" zeev@zend.com:
From: Derick Rethans [mailto:derick@php.net]
Sent: Tuesday, October 22, 2013 12:12 PMI have started the vote for extended keyword support RFC:
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
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
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
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:
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
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
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.
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.
+1 on idea
-1 on implementation
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.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