Hey,
I feel like concatenation having the same precedence than addition and subtraction is promoting programmers to make mistakes. Albeit typically easy to catch ones, it is a quality of life change at least.
Hence I'm proposing a RFC changing the precedences:
https://wiki.php.net/rfc/concatenation_precedence
Bob
Hello,
On the one hand - seems logical.
On the other hand - makes things less clear when reading the code.
With parenthesis, the code is made explicit, so you treat code like given
in an example as a code smell.
I'd encourage people to always use parentheses. But overall I'd say the
change makes sense.
чт, 28 мар. 2019 г. в 15:33, Bob Weinand bobwei9@hotmail.com:
Hey,
I feel like concatenation having the same precedence than addition and
subtraction is promoting programmers to make mistakes. Albeit typically
easy to catch ones, it is a quality of life change at least.Hence I'm proposing a RFC changing the precedences:
https://wiki.php.net/rfc/concatenation_precedenceBob
--
Arvīds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius
Hi!
I feel like concatenation having the same precedence than addition
and subtraction is promoting programmers to make mistakes. Albeit
typically easy to catch ones, it is a quality of life change at
least.
Changing operator precedence is usually a very bad idea, because it
tends to break code in random places that are very hard to detect.
Unless there's a huge reason to do it - and eliminating a couple of
parentheses is usually not - I'd stay away from such things. If you have
any doubts about precedence - just put the parentheses and forget about it.
--
Stas Malyshev
smalyshev@gmail.com
It makes sense to me. Can you perform some tests with big projects that
uses PHPUnit, at least? It will help to identify BC.
Em qui, 28 de mar de 2019 às 10:33, Bob Weinand bobwei9@hotmail.com
escreveu:
Hey,
I feel like concatenation having the same precedence than addition and
subtraction is promoting programmers to make mistakes. Albeit typically
easy to catch ones, it is a quality of life change at least.Hence I'm proposing a RFC changing the precedences:
https://wiki.php.net/rfc/concatenation_precedenceBob
--
David Rodrigues
Hey,
I feel like concatenation having the same precedence than addition and subtraction is promoting programmers to make mistakes. Albeit typically easy to catch ones, it is a quality of life change at least.
Hence I'm proposing a RFC changing the precedences:
https://wiki.php.net/rfc/concatenation_precedenceBob
Hey Bob,
if we decide to do this, there should definitely be a deprecation
notice in 7.4, I wouldn't even add a vote option for this, but make it
part of the primary vote.
An alternative to prevent mistakes in this regard is making this a
compile error and requiring parenthesis.
Regards,
Niklas
An alternative to prevent mistakes in this regard is making this a
compile error and requiring parenthesis.
If we're going to changes any precedence in the language, please please
please can we look at the ternary operator associativity?
I think making it non-associative, so that you have to use parentheses
in "$a ? $b : $c ? $d : $e" would break very little code, in an obvious
way, and help with a major pain point people have with the language.
Regards,
--
Rowan Collins
[IMSoP]
Den 2019-04-01 kl. 23:37, skrev Rowan Collins:
An alternative to prevent mistakes in this regard is making this a
compile error and requiring parenthesis.If we're going to changes any precedence in the language, please
please please can we look at the ternary operator associativity?I think making it non-associative, so that you have to use parentheses
in "$a ? $b : $c ? $d : $e" would break very little code, in an
obvious way, and help with a major pain point people have with the
language.Regards,
I recall that this was up for discussion a few years back for PHP 7.0, see:
https://marc.info/?l=php-internals&m=141851165925502
r//Björn L
Hey,
I feel like concatenation having the same precedence than addition and
subtraction is promoting programmers to make mistakes. Albeit typically
easy to catch ones, it is a quality of life change at least.Hence I'm proposing a RFC changing the precedences:
https://wiki.php.net/rfc/concatenation_precedenceBob
Similarly to the ternary associativity RFC, I've analyzed the top 2000
composer packages and checked whether they would be affected by this
change: https://gist.github.com/nikic/a4df3e8e18c7955c2c21cf6cdb4cbfaa
The tl;dr is that there were 5 instances where behavior would change per
this RFC, and all 5 of them are bugs in current code and would be
interpreted correctly after this RFC.
Nikita
I feel like concatenation having the same precedence than addition and
subtraction is promoting programmers to make mistakes. Albeit typically
easy to catch ones, it is a quality of life change at least.Hence I'm proposing a RFC changing the precedences:
https://wiki.php.net/rfc/concatenation_precedenceSimilarly to the ternary associativity RFC, I've analyzed the top 2000
composer packages and checked whether they would be affected by this
change: https://gist.github.com/nikic/a4df3e8e18c7955c2c21cf6cdb4cbfaaThe tl;dr is that there were 5 instances where behavior would change per
this RFC, and all 5 of them are bugs in current code and would be
interpreted correctly after this RFC.
Nikita, impressive leg work; thanks. It validates Bob's intuition from the
RFC ("... these occurrences are quite rare as it almost always is an error
in the current form, rendering the impact minimal."), so I'd encourage
bringing this to a vote. I'm a +1.
Hi!
Nikita, impressive leg work; thanks. It validates Bob's intuition from the
RFC ("... these occurrences are quite rare as it almost always is an error
in the current form, rendering the impact minimal.")
If the impact is minimal, why do it at all? So, at the cost of BC break
and breaking old code (which is most definitely not in composer packages
and likely isn't publicly accessible) we maybe fix 5 bugs. Does this
justify a BC break? I don't think so. I really wish we'd stop trying to
add a thousand small incompatibilities between PHP 7 and PHP 8.
--
Stas Malyshev
smalyshev@gmail.com
Hi!
Nikita, impressive leg work; thanks. It validates Bob's intuition from the
RFC ("... these occurrences are quite rare as it almost always is an error
in the current form, rendering the impact minimal.")If the impact is minimal, why do it at all? So, at the cost of BC break
and breaking old code (which is most definitely not in composer packages
and likely isn't publicly accessible) we maybe fix 5 bugs. Does this
justify a BC break? I don't think so. I really wish we'd stop trying to
add a thousand small incompatibilities between PHP 7 and PHP 8.
I wish we could stop having this conversation on this list over and
over. A certain level of backwards compatibility is essential, but
beyond that you limit the future by the mistakes of the past. In a
language like PHP a lot of mistakes were made, which greatly limits
the future. Every time I try to add a feature which ought not to break
anything I discover some horror in our language. Fixing bugs are often
just as bad.
Now, back to this particular BC break: it doesn't really enable a lot
of future things, so here I can understand the resistance. Personally,
I am slightly in favor of it. It seems like the precedence of
concatenation ought to be lower than most other operators, because it
doesn't make sense to use those operators on the result of the
concatenation. This has occasionally caused small bugs in our code,
and would prefer to fix it long-term.
On Sun, Apr 28, 2019 at 9:45 PM Stanislav Malyshev smalyshev@gmail.com
wrote:
Nikita, impressive leg work; thanks. It validates Bob's intuition from
the
RFC ("... these occurrences are quite rare as it almost always is an
error
in the current form, rendering the impact minimal.")If the impact is minimal, why do it at all? So, at the cost of BC break
and breaking old code (which is most definitely not in composer packages
and likely isn't publicly accessible) we maybe fix 5 bugs. Does this
justify a BC break? I don't think so. I really wish we'd stop trying to
add a thousand small incompatibilities between PHP 7 and PHP 8.
Because when the language becomes more obvious and intuitive, our users
benefit.
Code that appears to produce a particular result actually produces that
result. No WTF trap for users to fall into. No questions sent to mailing
lists or SO asking "why", and no documentation written to explain away that
why. Because there simply isn't a why; it's just the way it is. No
justification suffices.
We have the opportunity to exchange the way it is, for the way it should
have been. I think we should accept that opportunity.
Am 25.04.2019 um 11:52 schrieb Nikita Popov <nikita.ppv@gmail.commailto:nikita.ppv@gmail.com>:
Hey,
I feel like concatenation having the same precedence than addition and subtraction is promoting programmers to make mistakes. Albeit typically easy to catch ones, it is a quality of life change at least.
Hence I'm proposing a RFC changing the precedences:
https://wiki.php.net/rfc/concatenation_precedence
Bob
Similarly to the ternary associativity RFC, I've analyzed the top 2000 composer packages and checked whether they would be affected by this change: https://gist.github.com/nikic/a4df3e8e18c7955c2c21cf6cdb4cbfaa
The tl;dr is that there were 5 instances where behavior would change per this RFC, and all 5 of them are bugs in current code and would be interpreted correctly after this RFC.
Nikita
Thanks for the analysis,
Given the confirmation that the impact is minimal (rather beneficial), I'll add this to the RFC and start voting tomorrow.
Bob
Hey,
I feel like concatenation having the same precedence than addition and
subtraction is promoting programmers to make mistakes. Albeit typically
easy to catch ones, it is a quality of life change at least.Hence I'm proposing a RFC changing the precedences:
https://wiki.php.net/rfc/concatenation_precedenceBob
Similarly to the ternary associativity RFC, I've analyzed the top 2000
composer packages and checked whether they would be affected by this
change: https://gist.github.com/nikic/a4df3e8e18c7955c2c21cf6cdb4cbfaaThe tl;dr is that there were 5 instances where behavior would change per
this RFC, and all 5 of them are bugs in current code and would be
interpreted correctly after this RFC.
Nikita,
I'm a bit worried that using this as a standard test suite may
(repeatedly?) give us a false sense of security to go ahead with
compatibility breaking changes.
Composer packages, almost by definition - tend to be of higher quality than
the 'average' PHP code (at the very least they're redistributable, but
arguably Composer users are more advanced than the average developer - even
more so those who publish packages). On top of that - probably the some of
the most redistributed pieces of code in the PHP space - aren't covered by
Composer at all (e.g. WordPress).
Don't get me wrong - I think it's great to have this indicator, but unless
I'm missing something, it's far from being something we can thoroughly rely
on to determine whether a certain feature is commonly used or not. A huge
chunk of the PHP codebase is completely invisible to us, and much of the
code that is visible to us does not reside inside Composer.
Zeev
On Thu, Apr 25, 2019 at 12:52 PM Nikita Popov nikita.ppv@gmail.com
wrote:Hey,
I feel like concatenation having the same precedence than addition and
subtraction is promoting programmers to make mistakes. Albeit typically
easy to catch ones, it is a quality of life change at least.Hence I'm proposing a RFC changing the precedences:
https://wiki.php.net/rfc/concatenation_precedenceBob
Similarly to the ternary associativity RFC, I've analyzed the top 2000
composer packages and checked whether they would be affected by this
change: https://gist.github.com/nikic/a4df3e8e18c795
https://gist.github.com/nikic/a4df3e8e18c7955c2c21cf6cdb4cbfaaZeev
5c2c21cf6cdb4cbfaa
https://gist.github.com/nikic/a4df3e8e18c7955c2c21cf6cdb4cbfaaThe tl;dr is that there were 5 instances where behavior would change per
this RFC, and all 5 of them are bugs in current code and would be
interpreted correctly after this RFC.Nikita,
I'm a bit worried that using this as a standard test suite may
(repeatedly?) give us a false sense of security to go ahead with
compatibility breaking changes.
Composer packages, almost by definition - tend to be of higher quality
than the 'average' PHP code (at the very least they're redistributable, but
arguably Composer users are more advanced than the average developer - even
more so those who publish packages). On top of that - probably the some of
the most redistributed pieces of code in the PHP space - aren't covered by
Composer at all (e.g. WordPress).
Even if something is not published via packagist proper, it will commonly
be redistributed there. E.g. in the dataset I used, WordPress is
represented through the roots/wordpress package (a packagist mirror of
WordPress).
Don't get me wrong - I think it's great to have this indicator, but unless
I'm missing something, it's far from being something we can thoroughly rely
on to determine whether a certain feature is commonly used or not. A huge
chunk of the PHP codebase is completely invisible to us, and much of the
code that is visible to us does not reside inside Composer.
Absolutely. This only looks at a very small fraction of PHP code, though
also at a very important fraction. We do need to be carefully about where
and how the methodology is applied, for example it would make very little
sense to use this approach to analyze short tags usage -- that's clearly
something that will be predominantly found in proprietary template code,
not inside open-source libraries that have no need for templates to begin
with.
TBH my main concern with this change is not the BC impact, but the concept
of doing precedence changes at all. This is going to be a pain for 3rd
party tooling, e.g. I'll have to add an entirely separate parser for PHP 8
to the PHP-Parser library.
Nikita
On Thu, Apr 25, 2019 at 12:52 PM Nikita Popov nikita.ppv@gmail.com
wrote:On Thu, Mar 28, 2019 at 2:33 PM Bob Weinand bobwei9@hotmail.com
wrote:Hey,
I feel like concatenation having the same precedence than addition and
subtraction is promoting programmers to make mistakes. Albeit
typically
easy to catch ones, it is a quality of life change at least.Hence I'm proposing a RFC changing the precedences:
https://wiki.php.net/rfc/concatenation_precedenceBob
Similarly to the ternary associativity RFC, I've analyzed the top 2000
composer packages and checked whether they would be affected by this
change: https://gist.github.com/nikic/a4df3e8e18c795
https://gist.github.com/nikic/a4df3e8e18c7955c2c21cf6cdb4cbfaaZeev
5c2c21cf6cdb4cbfaa
https://gist.github.com/nikic/a4df3e8e18c7955c2c21cf6cdb4cbfaaThe tl;dr is that there were 5 instances where behavior would change per
this RFC, and all 5 of them are bugs in current code and would be
interpreted correctly after this RFC.Nikita,
I'm a bit worried that using this as a standard test suite may
(repeatedly?) give us a false sense of security to go ahead with
compatibility breaking changes.
Composer packages, almost by definition - tend to be of higher quality
than the 'average' PHP code (at the very least they're redistributable,
but
arguably Composer users are more advanced than the average developer -
even
more so those who publish packages). On top of that - probably the some
of
the most redistributed pieces of code in the PHP space - aren't covered
by
Composer at all (e.g. WordPress).Even if something is not published via packagist proper, it will commonly
be redistributed there. E.g. in the dataset I used, WordPress is
represented through the roots/wordpress package (a packagist mirror of
WordPress).
That's good to know - thanks!
Don't get me wrong - I think it's great to have this indicator, but unless
I'm missing something, it's far from being something we can thoroughly
rely
on to determine whether a certain feature is commonly used or not. A
huge
chunk of the PHP codebase is completely invisible to us, and much of the
code that is visible to us does not reside inside Composer.Absolutely. This only looks at a very small fraction of PHP code, though
also at a very important fraction. We do need to be carefully about where
and how the methodology is applied, for example it would make very little
sense to use this approach to analyze short tags usage -- that's clearly
something that will be predominantly found in proprietary template code,
not inside open-source libraries that have no need for templates to begin
with.TBH my main concern with this change is not the BC impact, but the concept
of doing precedence changes at all. This is going to be a pain for 3rd
party tooling, e.g. I'll have to add an entirely separate parser for PHP 8
to the PHP-Parser library.
Agreed on both. I hope folks factor that into account when they review the
results of this tool before deciding about deprecations.
Thanks,
Zeev
Nikita,
I'm a bit worried that using this as a standard test suite may
(repeatedly?) give us a false sense of security to go ahead with
compatibility breaking changes.
Composer packages, almost by definition - tend to be of higher quality
than the 'average' PHP code (at the very least they're redistributable, but
arguably Composer users are more advanced than the average developer - even
more so those who publish packages). On top of that - probably the some of
the most redistributed pieces of code in the PHP space - aren't covered by
Composer at all (e.g. WordPress).
Is this scanner available in a form that users could run it against
their code basis and have it report to a server, perhaps after showing
what it would report?
This way, users and less polished code could be put to the same test.
-Clint
Am Mo., 29. Apr. 2019 um 09:03 Uhr schrieb Bob Weinand bobwei9@hotmail.com:
Am 25.04.2019 um 11:52 schrieb Nikita Popov <nikita.ppv@gmail.commailto:nikita.ppv@gmail.com>:
Hey,
I feel like concatenation having the same precedence than addition and subtraction is promoting programmers to make mistakes. Albeit typically easy to catch ones, it is a quality of life change at least.
Hence I'm proposing a RFC changing the precedences:
https://wiki.php.net/rfc/concatenation_precedenceBob
Similarly to the ternary associativity RFC, I've analyzed the top 2000 composer packages and checked whether they would be affected by this change: https://gist.github.com/nikic/a4df3e8e18c7955c2c21cf6cdb4cbfaa
The tl;dr is that there were 5 instances where behavior would change per this RFC, and all 5 of them are bugs in current code and would be interpreted correctly after this RFC.
Nikita
Thanks for the analysis,
Given the confirmation that the impact is minimal (rather beneficial), I'll add this to the RFC and start voting tomorrow.
Bob
Maybe we should have a longer timeframe and deprecate in 8.0 and
change precedence in 9.0, similar to how it might be done with ?:
changing to non-assoc in 8.0 and maybe right-assoc in 9.0 or 10.0?
Should we have a secondary vote for that?
Regards, Niklas