On Mon, Apr 29, 2019 at 10:55 AM Nikita Popov <nikita....@gmail.com> wrote:
> On Mon, Apr 29, 2019 at 9:34 AM Zeev Suraski <z...@php.net> wrote: > > > > > > > On Thu, Apr 25, 2019 at 12:52 PM Nikita Popov <nikita....@gmail.com> > > wrote: > > > >> On Thu, Mar 28, 2019 at 2:33 PM Bob Weinand <bobw...@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_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/a4df3e8e18c795 > >> <https://gist.github.com/nikic/a4df3e8e18c7955c2c21cf6cdb4cbfaa> > >> > >> Zeev > >> > >> 5c2c21cf6cdb4cbfaa > >> <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'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
