Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105502
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=turbo-smtp; d=php.net;
	h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type;
	b=ApflcykA/WJ7s3uvhOIQtRLhQKDXURkxISbaGSgikIJ1cZt/NSBwZ+mfuUNGbi
	ErBfC4vWWQ+kVzd6f3oiuJr4wuEcF0DW+mImG4SsArjN8XfgVIKAhILoTy0K5f3h
	yI2jBPrMmbjgOBb+psGrtZw2RyKipnEiZgQMzzHT4HpyA=;
MIME-Version: 1.0
References: <DB6PR0701MB3048010E7D55F49CEAB98927E2590@DB6PR0701MB3048.eurprd07.prod.outlook.com> <CAF+90c9X34yHpHO5aTYZ0-KJLRWQnNkbf_me=f_GyX61jVnghA@mail.gmail.com> <CAJHtznyiD_yGzHDV930H6SFMCh6FykdYkuwNkn1=bcd+C=chKw@mail.gmail.com> <CAF+90c8gA31GYk1ucF4oU+3mGRbewEdnYT0Vma8a2TywQieC7A@mail.gmail.com>
In-Reply-To: <CAF+90c8gA31GYk1ucF4oU+3mGRbewEdnYT0Vma8a2TywQieC7A@mail.gmail.com>
Date: Mon, 29 Apr 2019 11:05:34 +0300
Message-ID: <CAJHtzny6W2LJZwDgFUYkV+hj+KXgk7ossCzQq7L+vYsEHxcFzg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Bob Weinand <bobwei9@hotmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006316e00587a6c0de"
Subject: Re: [PHP-DEV] [RFC] Change the precedence of the concatenation operator
From: zeev@php.net (Zeev Suraski)

--0000000000006316e00587a6c0de
Content-Type: text/plain; charset="UTF-8"

On Mon, Apr 29, 2019 at 10:55 AM Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Mon, Apr 29, 2019 at 9:34 AM Zeev Suraski <zeev@php.net> wrote:
>
> >
> >
> > 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_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

--0000000000006316e00587a6c0de--