Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116132 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 55685 invoked from network); 22 Sep 2021 13:45:28 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 22 Sep 2021 13:45:28 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 3E20018053D for ; Wed, 22 Sep 2021 07:26:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 22 Sep 2021 07:26:39 -0700 (PDT) Received: by mail-lf1-f51.google.com with SMTP id p29so12440931lfa.11 for ; Wed, 22 Sep 2021 07:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=usWNq3D2nQNblfkDzRFixCFTCRy3E+kSEdj3hXGPpuk=; b=WttcOS+7f8xpx3OwZ4hxiE4hmcqTJIyYiYm0YMtNtSxM2HgJMqzq+rdm5CDFgFFdDo /PMw1ohlH3w461pQ/1YyoW/Fq2pn9b/E9Rr0NqE8g7fJZfw6W8czxbRX2rFscP57jTkz XWIjBRDx7Zjjc1HWlXs35rkZPWxil0PRoYv6Q7RxNgEwJA0WcOZsmg+x3lq/NLCVD5QR bQltwHWtn2FGd/szIa8aP6J/BiDYrg79ZG35ehXIx530mAjIlgAX+GH2rAkOr8tvuwlJ YCRVq4+6iFENynCoFEjIlCQwVH8WfMpLWBZlqwpFoLwIYwNpCvSqAO+0xtx+ui/BwOCb 7UZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=usWNq3D2nQNblfkDzRFixCFTCRy3E+kSEdj3hXGPpuk=; b=5GEkbLuF2eYFOOksEhkLO8CS/wFis+Ls4j1+oV9G0bLigI6kaKFPoT8YmAGxAHTwxP uK2DwChtWp8yaopp27jkBW0th6ZGAxAWJUo/8/OmmExkgt/c59lf3IFr5XBoIhGfeYCL fjgkHIaPt0xkNUm411tfjsnNBzpn7o5GRRNQQ+jOqHII+c+rP7HSNvWTRspao4AulO4c CXjpo+vNxuE/j/oLOEJCPJ5GWUWNvNNUckLQ3oAzkjzxjIBZMCcsvy5UrwgetFUWOtC4 c1IeTWqZrX//1qAekwMPjyTp+7RQu89XdLOsDNaUBRmcZBStLHdKJRcClcuifAXErTMg SkNA== X-Gm-Message-State: AOAM532ADfYCkNbaGpDnCPc/nWQ55eid/fJIlgjXduBphfdxlOuXFs4D +S3rdaSxoSw1gjRJV3V3Sq8N3s0oQnIypSPQ1Kcdi9QD X-Google-Smtp-Source: ABdhPJzHZsA0p+jt9qpFSYkcysuNsd50xQ3qrkJMLljUvmEr0PgZz06yqOFtyJYMF1GbGq+eAuRSe3OUQyc54YCscsQ= X-Received: by 2002:a2e:958a:: with SMTP id w10mr14099831ljh.13.1632320689004; Wed, 22 Sep 2021 07:24:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 22 Sep 2021 09:24:37 -0500 Message-ID: To: "G. P. B." Cc: PHP Developers Mailing List Content-Type: multipart/alternative; boundary="000000000000d3e57e05cc9646dc" Subject: Re: [PHP-DEV] BC breaking changes in PHP 8.1 From: mweierophinney@gmail.com ("Matthew Weier O'Phinney") --000000000000d3e57e05cc9646dc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 22, 2021 at 9:01 AM G. P. B. wrote: > On Wed, 22 Sept 2021 at 14:30, Matthew Weier O'Phinney < > mweierophinney@gmail.com> wrote: > >> Yesterday, I opened an issue regarding a change in the pgsql extension ( >> https://bugs.php.net/bug.php?id=3D81464). >> >> PHP 8.0 introduced the concept of "resource objects". Where previously w= e >> would have resources, and use `get_resource_type()` when we needed to >> differentiate various resources, resource objects give us immutable >> objects >> instead that allow us to type hint. Personally, I think this is wonderfu= l! >> >> The rollout for 8.0 was incomplete, however, and only touched on somethi= ng >> like 4-6 different resource types. Still, a good start. >> >> With PHP 8.1, we're seeing the addition of more of these, and it was >> encountering one of those changes that prompted the bug I previously >> linked >> to. >> >> Here's the issue: while overall, I like the move to resource objects, >> introducing them in a MINOR release is hugely problematic. >> >> Previously, you would do constructs such as the following: >> >> if (! is_resource($resource) || get_resource_type($resource) !=3D=3D >> $someSpecificType) { >> // skip a test or raise an exception >> } >> >> Resource objects, however: >> >> - Return `false` for `is_resource()` checks. >> - Raise a warning for `get_resource_type()` checks, and/or report the >> resource object class name =E2=80=94 which differs from the previous res= ource >> names >> in all cases. >> >> This means conditionals like the above BREAK. As a concrete example, I d= id >> PHP 8.1 updates for laminas-db last week, and assumed our postgres >> integration tests were running when we finally had all tests passing >> successfully. However, what was really happening was that our test suite >> was testing with `is_resource()` and skipping tests if resources were no= t >> present. We shipped with broken pgsql support as a result, and it wasn't >> until test suites in other components started failing that we were able = to >> identify the issue. >> >> Further, the "fix" so that the code would work on both 8.1 AND versions >> prior to 8.1 meant complicating the conditional, adding a `! $resource >> instanceof \PgSql\Connection` into the mix. The code gets unwieldy very >> quickly, and having to do this to support a new minor version was >> irritating. >> >> When I opened the aforementioned bug report, it was immediately closed a= s >> "not an issue" with the explanation that it was "documented in UPGRADING= ". >> >> This is not an acceptable explanation. >> >> - There was no RFC related to 8.1 indicating these changes were happenin= g. >> (In fact, there was no RFC for resource objects in the first place =E2= =80=94 which >> is concerning considering the BC implications!) >> - In semantic versioning, existing APIs MUST NOT change in a new minor >> version, only in new major versions. >> >> Reading the UPGRADING guide, there's a HUGE section of backwards >> incompatible changes for 8.1 =E2=80=94 THIRTY-FOUR of them. Nested in th= ese are >> notes of around a half-dozen extensions that once produced resources now >> producing resource objects. >> >> The pace of change in PHP is already breathtaking when you consider larg= e >> projects (both OSS and in userland); keeping up with new features is in >> and >> of itself quite a challenge. Introducing BC breaks in minor versions mak= es >> things harder for everyone, as now you have to figure out not only if >> there's new features you want to adopt, but whether or not there are >> changes that will actively break your existing code. I strongly feel tha= t >> anything in the backwards incompatible section of the UPGRADING guide >> should be deferred to 9.0, when people actually expect things to change. >> > > Resource to object conversions have precedent for not being in a major > version: > GMP in PHP 5.6 > Hash in PHP 7.2 > > The fix to how to check these conditions is the same as last year and it > is to check against false, not is_resource nor an instance of the class. > It is true that if you ensure that the resource type is correct it gets > slightly unwieldy but: > > if ($resource !=3D=3D false && ((is_resource($resource) && > get_resource_type($resource) =3D=3D=3D $someSpecificType) || $resource in= stanceof > ClassName) ) { > // skip a test or raise an exception > } > > Should be identical to the changes made to support PHP 5.6, 7.2, and 8.0 > in regards to the other conversions, and I don't see why it is now an iss= ue. > We also *explicitly* hold off from pouring more of our time in resources > to object conversions during the Beta cycle of PHP 8.0 as we knew we coul= d > defer this to a later minor version, compared to promotions from E_WARNIN= G > to Exceptions which took a huge amount of last summer. > > PHP tries to broadly follow semantic versioning but it *never* has adhere= d > to it strictly, and this is not uncommon within programming languages > nomenclature (e.g. Python). > > Moreover, many changes to php-src are based, and a result of this > refactoring from resources to objects, so it isn't just a simple "revert > commit", especially as we are in the RC phase. > > Albeit this is only my opinion, this is still not a bug, and I frankly > don't think any of it should be reverted as we, the core team, are never > going to be able to convert all of the resource to objects in time for a > major release, except if we decide that each year PHP is getting a major > release and we throw minor versions out of the windows. > With changes like this, though, PHP is **already** de facto doing major releases every year. If internals buys the argument Kamil makes that "PHP does not follow semantic versioning", then: - Stop using semantic versioning numbers, as the numbers lead to (appropriate) user expectations about stability. - Or start numbering versions properly, and call each minor a new major, so users know what to expect. > As somebody who's been contributing to and maintaining OSS libraries forever (since 2002), the pace of change of PHP is, frankly, ridiculous. I can keep up with patches. I can keep up with new features. But BC breaks EVERY YEAR just creates churn. I've spent most of the past 18 months doing nothing but ensuring libraries work on new PHP versions. I then get users angry that they aren't getting new features; if I don't update to the latest PHP version, I get other users angry they can't use the library on the newer PHP version. And with new PHP versions every year... I essentially have to update every 2-3 years regardless, and will lose users if I don't do it every year. Figure out what the BC breaks are going to be, and do them all at once. It's far easier for the ecosystem to adapt to a big drop of BC breaks every 3-5 years than it is every year. Again, I DO like the resource objects feature. But getting a few here and there over many minor releases is a lot of breakage to track and adapt to. And that's just the tip of the iceberg. --=20 Matthew Weier O'Phinney mweierophinney@gmail.com https://mwop.net/ he/him --000000000000d3e57e05cc9646dc--