Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125805
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 15 Oct 2024 12:11:25 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <9399e880-f51d-4726-b4fa-9833e82ef2e0@app.fastmail.com>
In-Reply-To: 
 <CAEZPtU4JzVvOkrGpr_LSrMHyVaFh1xTTP6DXgz1JwA=zPqXbyA@mail.gmail.com>
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>
Subject: Re: [PHP-DEV] Asymmetric visibility is a BC break
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Oct 14, 2024, at 10:27 PM, Pierre Joye wrote:
> Hello,
>
> On Mon, Oct 14, 2024, 8:07=E2=80=AFAM Bilge <bilge@scriptfusion.com> w=
rote:
>> On 14/10/2024 01:02, Valentin Udaltsov wrote:
>> > The problem is that in practice most of the PHP libraries consider
>> > themselves to be compatible with newer PHP versions.
>> >
>> > For instance, Symfony PropertyInfo uses `"php": ">=3D8.2"` constrai=
nt in
>> > its `composer.json`.
>>=20
>> That seems like a problem they have created for themselves. It seems =
an=20
>> error to me to declare software forward-compatible with PHP versions=20
>> that do not yet exist and thus have clearly not been tested against.=20
>> Being as it is an error, we shouldn't consider it impinges on PHP's=20
>> definition of a BC break.
>
>
> As much as I like this new feature and I am more than thankful for the=20
> work behind it, if a test in codes using a x.y version of php works bu=
t=20
> fails in x.y+1, it is a BC break, no matter how we look at it. A php=20
> dependency targeting x.* is very common. While it tends to be used les=
s=20
> frequently as the amount of issues increase, that's not necessarly a=20
> good thing.
>
> In some cases it is a necessary evil (extension deprecated adding=20
> warnings, security fix requiring a bc break, f.e.).
>
> However, I am very doubtful here. And I do not know if it can be=20
> avoided while keeping the new behaviors.=20
>
> All in all, it would be great to at least agree that there is a BC=20
> break issue, so it can be addressed according, whatever the final=20
> decision is.
>
> best,
> Pierre


I think folks are operating with different definitions of "BC Break".

Consider:

// Foreign.php

class Foreign {
  public function __construct(public string $name) {}
}

// My code:

$f =3D new Foreign('beep');
$rProp =3D (new ReflectionObject($f))->getProperty('name');
if ($rProp->isPublic()) {
  $f->name =3D 'boop';
}

Under PHP 8.0, this code works.
Upgrading to PHP 8.1, this code *still works* exactly the same.  Therefo=
re, there is no BC break.
Upgrading to PHP 8.4, this code *still works* exactly the same.  Therefo=
re, there is no BC break.

Now, someone edits Foreign.php in 8.1 to read:

class Foreign {
  public function __construct(public readonly string $name) {}
}

Now, my code will fail, because isPublic() does not guarantee "is writea=
ble" anymore. =20

Is this a BC break in PHP?

I can see the argument either way, personally, but I tend toward no.  On=
e 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 s=
ame.  We want that.  However, once you start modifying any part of the c=
ode (including dependencies), all bets are off.

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 P=
HP.  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 priv=
ate properties.  Is that a PHP BC break?  Not at all.

And again, the relevant change here happened in PHP 8.1.  This is only t=
angentially related to 8.4 at all, because isPublic() has not implicitly=
 meant is-writeable anymore for three years.

--Larry Garfield