Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105500 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 84910 invoked from network); 29 Apr 2019 10:53:32 -0000 Received: from unknown (HELO mail-lf1-f66.google.com) (209.85.167.66) by pb1.pair.com with SMTP; 29 Apr 2019 10:53:32 -0000 Received: by mail-lf1-f66.google.com with SMTP id t11so7067312lfl.12 for ; Mon, 29 Apr 2019 00:55:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4Uw8hlikxTf3izdz1xNxDV8WbF5ugd3OaOhCZWQrbwo=; b=Sy4pVcXLRzDn3IUzs8XAgvK2o+vfHxaHgGCMLdN6EIooMdZnqE/G2fE/YXeLcuIoGM 63UNKe+vDsh6afv5KnpMuq1uTE6RXrQrG5HMyy6uQDUWlueqkCE3OtkLRy34/U5xZ5Rx jIm1Ex7MyN1Jbqq7wx+22paKWmXBd7ZSpvidXKSrZ3Q5Fs3CvUBcDxzjOHk8zedD9rg1 6tP1SYVWT5HdSHB8C1GyTG7llgnHRjwirOCAu/SL8sF4ywYK/b4tOnYXr9hAS0BJcILb y/5xMznR+r5ae8+ExKiyjJXrpWkxO5xiRxLtb6yLJKiUDfkksz96lKIwL9t9M5SDy5eQ 7MkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4Uw8hlikxTf3izdz1xNxDV8WbF5ugd3OaOhCZWQrbwo=; b=BvkyvPk8uHjUgOaXhKgyQhs2yCx51E9u7Ipb10GDY3q6c0/uM7ZrodSNC419tMbzfy nEVTzuu/HUaHdzlMMh44DIifblTvaR0VYthWHA7fc37uhXuCgT6eAh5JoE89tJJcdRzX GkyIP8R2UbjFw1B8mf9BD0nu1c6kAader0Rsrm0d6qOUydnKVa8Clwy7KF27eFIibGLG 2dofx9LhfnLT8BVUarOvDucOAolHHRugvbDhiMDlXBtHM5wgtZCBQndzV9cAvxrnVb/1 BYJx4THbR+0XKYHte2qu5jp33NDqtTEFfNJ4LRNWaRVjWp4hJzj1ymCPBxPGbS/GQJNB 8RIA== X-Gm-Message-State: APjAAAUdIACJnkk3xaSADv/Ee92LNwTUMJ0i5jiC1I0QfVWJL5r3nH17 buK6LoT8YSuJGgMibleAGrTSJFAERNbafjXE1rM= X-Google-Smtp-Source: APXvYqxmuou5HI3VENvIVg8CrZLLtz4TzF/aMjzQI0ar7PbDOdL34DclL9XA10x0ylGupkUm18X+8nPpEdHlvgJCX9s= X-Received: by 2002:a19:3845:: with SMTP id d5mr31735961lfj.77.1556524522506; Mon, 29 Apr 2019 00:55:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 29 Apr 2019 09:55:05 +0200 Message-ID: To: Zeev Suraski Cc: Bob Weinand , PHP internals Content-Type: multipart/alternative; boundary="0000000000003f8e570587a69b89" Subject: Re: [PHP-DEV] [RFC] Change the precedence of the concatenation operator From: nikita.ppv@gmail.com (Nikita Popov) --0000000000003f8e570587a69b89 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 29, 2019 at 9:34 AM Zeev Suraski wrote: > > > On Thu, Apr 25, 2019 at 12:52 PM Nikita Popov > wrote: > >> On Thu, Mar 28, 2019 at 2:33 PM Bob Weinand 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 >> >> >> Zeev >> >> 5c2c21cf6cdb4cbfaa >> >> >> 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). 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 --0000000000003f8e570587a69b89--