Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116128
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
In-Reply-To: <CAJp_myX3J8gUb3885KAdEz+xokpZ_mz1Gs_DrN2Tp+JYfewcEw@mail.gmail.com>
Date: Wed, 22 Sep 2021 10:41:00 -0300
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <20A7B84B-3AEE-4E85-94BE-F2C6DFDA928F@cmpct.info>
References: <CAJp_myX3J8gUb3885KAdEz+xokpZ_mz1Gs_DrN2Tp+JYfewcEw@mail.gmail.com>
To: Matthew Weier O'Phinney <mweierophinney@gmail.com>
Subject: Re: [PHP-DEV] BC breaking changes in PHP 8.1
From: calvin@cmpct.info (Calvin Buckley)

I suspect this is true (I have not tested yet to be sure) for the =
Toolkit for IBM i, since it looks at resource types for the same purpose =
(determine database connection type). Minor fix, but it is a BC break.

> On Sep 22, 2021, at 10:29 AM, Matthew Weier O'Phinney =
<mweierophinney@gmail.com> wrote:
>=20
> Yesterday, I opened an issue regarding a change in the pgsql extension =
(
> https://bugs.php.net/bug.php?id=3D81464).
>=20
> PHP 8.0 introduced the concept of "resource objects". Where previously =
we
> 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 =
wonderful!
>=20
> The rollout for 8.0 was incomplete, however, and only touched on =
something
> like 4-6 different resource types. Still, a good start.
>=20
> 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.
>=20
> Here's the issue: while overall, I like the move to resource objects,
> introducing them in a MINOR release is hugely problematic.
>=20
> Previously, you would do constructs such as the following:
>=20
>    if (! is_resource($resource) || get_resource_type($resource) !=3D=3D
> $someSpecificType) {
>        // skip a test or raise an exception
>    }
>=20
> Resource objects, however:
>=20
> - 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 =
resource names
> in all cases.
>=20
> This means conditionals like the above BREAK. As a concrete example, I =
did
> 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 =
not
> 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.
>=20
> 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.
>=20
> When I opened the aforementioned bug report, it was immediately closed =
as
> "not an issue" with the explanation that it was "documented in =
UPGRADING".
>=20
> This is not an acceptable explanation.
>=20
> - There was no RFC related to 8.1 indicating these changes were =
happening.
> (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.
>=20
> 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 =
these are
> notes of around a half-dozen extensions that once produced resources =
now
> producing resource objects.
>=20
> The pace of change in PHP is already breathtaking when you consider =
large
> 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 =
makes
> 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 =
that
> anything in the backwards incompatible section of the UPGRADING guide
> should be deferred to 9.0, when people actually expect things to =
change.
>=20
> --=20
> Matthew Weier O'Phinney
> mweierophinney@gmail.com
> https://mwop.net/
> he/him