Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125831
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.1\))
Subject: Re: [PHP-DEV] Asymmetric visibility is a BC break
In-Reply-To: <9399e880-f51d-4726-b4fa-9833e82ef2e0@app.fastmail.com>
Date: Wed, 23 Oct 2024 02:39:20 -0300
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <4DED696F-5A72-42F6-B224-C7A6B5AB658A@cmpct.info>
References: <CAPyeZ4N8GMiLNVCDGxdofcy6txBhng_i2UKUGpiS5bnZ-YcYvA@mail.gmail.com>
 <2A7CF24F-3AE3-4125-965F-C65431C42DFB@gmail.com>
 <CAPyeZ4MSc=Sw9UE0soCdBEnVAJ8wXHHhYqm88OffkvNLrHPxFw@mail.gmail.com>
 <e966cf16-794d-4827-9a5e-b0de780a5b91@app.fastmail.com>
 <30a41608-a1ea-40a9-8d2a-c53c508cd89f@jnvsor.net>
 <a6cdfe39-2a18-40b1-8da5-f49e9e7a7918@app.fastmail.com>
 <CAMrTa2FM4o6q8TXdBbuHfnD66vtqFBVL2Hw6_412Bf1r2T1QMg@mail.gmail.com>
 <CAPyeZ4M0LDzPBTjT_Qa-ccB73DNatGWdARg-mKMO1T1XmnTzUg@mail.gmail.com>
 <3648840e-5c73-49c9-bc89-105ed761e5c2@scriptfusion.com>
 <CAEZPtU4JzVvOkrGpr_LSrMHyVaFh1xTTP6DXgz1JwA=zPqXbyA@mail.gmail.com>
 <9399e880-f51d-4726-b4fa-9833e82ef2e0@app.fastmail.com>
To: Larry Garfield <larry@garfieldtech.com>
From: calvin@cmpct.info (Calvin Buckley)

On Oct 15, 2024, at 2:11=E2=80=AFPM, Larry Garfield =
<larry@garfieldtech.com> wrote:
>=20
> I think folks are operating with different definitions of "BC Break".
>=20
> Consider:
>=20
> // Foreign.php
>=20
> class Foreign {
>  public function __construct(public string $name) {}
> }
>=20
> // My code:
>=20
> $f =3D new Foreign('beep');
> $rProp =3D (new ReflectionObject($f))->getProperty('name');
> if ($rProp->isPublic()) {
>  $f->name =3D 'boop';
> }
>=20
> Under PHP 8.0, this code works.
> Upgrading to PHP 8.1, this code *still works* exactly the same.  =
Therefore, there is no BC break.
> Upgrading to PHP 8.4, this code *still works* exactly the same.  =
Therefore, there is no BC break.
>=20
> Now, someone edits Foreign.php in 8.1 to read:
>=20
> class Foreign {
>  public function __construct(public readonly string $name) {}
> }
>=20
> Now, my code will fail, because isPublic() does not guarantee "is =
writeable" anymore. =20
>=20
> Is this a BC break in PHP?
>=20
> I can see the argument either way, personally, but I tend toward no.  =
One PHP version to the next should always be safe to upgrade an =
*existing* code base.  Just swap out the PHP binary and it should still =
work the same.  We want that.  However, once you start modifying any =
part of the code (including dependencies), all bets are off.
>=20
> Suppose some library switched from using annotations to using =
attributes.  Any other code that was looking for those annotations is =
now broken, but it would be ridiculous to accuse attributes of having =
broken BC in PHP.  Or ancient PHP 4 code that just assumed all =
properties were public (which they were in PHP 4), now confronted with =
PHP 5 code that has private properties.  Is that a PHP BC break?  Not at =
all.
>=20
> And again, the relevant change here happened in PHP 8.1.  This is only =
tangentially related to 8.4 at all, because isPublic() has not =
implicitly meant is-writeable anymore for three years.
>=20
> --Larry Garfield

After discussing it and thinking about it for a few days, I agree it's
not a BC break. Existing code should be fine, and larger frameworks
that tend to rely on reflection trickery and such also tend to need
updates for newer PHP. The expectations don't really change.

I don't think we need to rush a solution in for 8.4 as long as we can
implement one with the existing APIs in userland. As Larry mentioned,
readonly (and hooks) already made the previous assumptions invalid by
8.1. As long as we can provide a polyfill and documentation (which
should also cover the readonly case in 8.1 too), I'm OK with deferring
isReadable/isWritable to 8.5.=