Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125806
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 15 Oct 2024 22:18:08 +0200
To: internals@lists.php.net
Message-ID: <d0381c8e-dcaf-4d5a-826b-d6112fa8e763@app.fastmail.com>
In-Reply-To: <9399e880-f51d-4726-b4fa-9833e82ef2e0@app.fastmail.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>
 <9399e880-f51d-4726-b4fa-9833e82ef2e0@app.fastmail.com>
Subject: Re: [PHP-DEV] Asymmetric visibility is a BC break
Content-Type: multipart/alternative;
 boundary=1dca82df820e46e491b130010a09720b
From: rob@bottled.codes ("Rob Landers")

--1dca82df820e46e491b130010a09720b
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 15, 2024, at 19:11, Larry Garfield wrote:
> 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>=
 wrote:
> >> 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"` constr=
aint in
> >> > its `composer.json`.
> >>=20
> >> That seems like a problem they have created for themselves. It seem=
s an=20
> >> error to me to declare software forward-compatible with PHP version=
s=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 t=
he=20
> > work behind it, if a test in codes using a x.y version of php works =
but=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 l=
ess=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
>=20
>=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.  There=
fore, there is no BC break.
> Upgrading to PHP 8.4, this code *still works* exactly the same.  There=
fore, 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 writ=
eable" 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 *existin=
g* 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 attribut=
es.  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 publi=
c (which they were in PHP 4), now confronted with PHP 5 code that has pr=
ivate 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 implicit=
ly meant is-writeable anymore for three years.
>=20
> --Larry Garfield
>=20

Hey Larry,

First, thank you for this feature. Second, attributes and annotations ar=
e a moot point. Adding attributes didn't render annotations broken and i=
s still (unfortunately) used today in many codebases running 8.3. So, in=
 other words, the deprecation of annotations is a framework/codebase/use=
r-level issue and totally unrelated to attributes and PHP as a language.=
 While attributes helped with that deprecation, it wasn't caused by them=
=E2=80=94people could have deprecated annotations without ever having at=
tributes.

According to Wikipedia (https://en.wikipedia.org/wiki/Backward_compatibi=
lity)

> In compilers <https://en.wikipedia.org/wiki/Compiler>, [and interprete=
rs] backward compatibility may refer to the ability of a compiler [or in=
terpreter] for a newer version of the language to accept source code of =
programs or data that worked under the previous version.

I think this is all we need: just a proper definition. Looking at the is=
sue at play, we can conclude that it isn't a BC break =E2=80=94 code tha=
t worked in 8.3 will continue to work in 8.4. Will things have to be upd=
ated (or in my case, rewritten basically from scratch)? Sure! But there,=
 it becomes a framework/codebase/user-level issue on whether they will r=
emain backwards compatible with older versions of PHP.

=E2=80=94 Rob
--1dca82df820e46e491b130010a09720b
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Tue, Oct 15,=
 2024, at 19:11, Larry Garfield wrote:<br></div><blockquote type=3D"cite=
" id=3D"qt" style=3D""><div>On Mon, Oct 14, 2024, at 10:27 PM, Pierre Jo=
ye wrote:<br></div><div>&gt; Hello,<br></div><div>&gt;<br></div><div>&gt=
; On Mon, Oct 14, 2024, 8:07=E2=80=AFAM Bilge &lt;<a href=3D"mailto:bilg=
e@scriptfusion.com">bilge@scriptfusion.com</a>&gt; wrote:<br></div><div>=
&gt;&gt; On 14/10/2024 01:02, Valentin Udaltsov wrote:<br></div><div>&gt=
;&gt; &gt; The problem is that in practice most of the PHP libraries con=
sider<br></div><div>&gt;&gt; &gt; themselves to be compatible with newer=
 PHP versions.<br></div><div>&gt;&gt; &gt;<br></div><div>&gt;&gt; &gt; F=
or instance, Symfony PropertyInfo uses `"php": "&gt;=3D8.2"` constraint =
in<br></div><div>&gt;&gt; &gt; its `composer.json`.<br></div><div>&gt;&g=
t;&nbsp;<br></div><div>&gt;&gt; That seems like a problem they have crea=
ted for themselves. It seems an&nbsp;<br></div><div>&gt;&gt; error to me=
 to declare software forward-compatible with PHP versions&nbsp;<br></div=
><div>&gt;&gt; that do not yet exist and thus have clearly not been test=
ed against.&nbsp;<br></div><div>&gt;&gt; Being as it is an error, we sho=
uldn't consider it impinges on PHP's&nbsp;<br></div><div>&gt;&gt; defini=
tion of a BC break.<br></div><div>&gt;<br></div><div>&gt;<br></div><div>=
&gt; As much as I like this new feature and I am more than thankful for =
the&nbsp;<br></div><div>&gt; work behind it, if a test in codes using a =
x.y version of php works but&nbsp;<br></div><div>&gt; fails in x.y+1, it=
 is a BC break, no matter how we look at it. A php&nbsp;<br></div><div>&=
gt; dependency targeting x.* is very common. While it tends to be used l=
ess&nbsp;<br></div><div>&gt; frequently as the amount of issues increase=
, that's not necessarly a&nbsp;<br></div><div>&gt; good thing.<br></div>=
<div>&gt;<br></div><div>&gt; In some cases it is a necessary evil (exten=
sion deprecated adding&nbsp;<br></div><div>&gt; warnings, security fix r=
equiring a bc break, f.e.).<br></div><div>&gt;<br></div><div>&gt; Howeve=
r, I am very doubtful here. And I do not know if it can be&nbsp;<br></di=
v><div>&gt; avoided while keeping the new behaviors.&nbsp;<br></div><div=
>&gt;<br></div><div>&gt; All in all, it would be great to at least agree=
 that there is a BC&nbsp;<br></div><div>&gt; break issue, so it can be a=
ddressed according, whatever the final&nbsp;<br></div><div>&gt; decision=
 is.<br></div><div>&gt;<br></div><div>&gt; best,<br></div><div>&gt; Pier=
re<br></div><div><br></div><div><br></div><div>I think folks are operati=
ng with different definitions of "BC Break".<br></div><div><br></div><di=
v>Consider:<br></div><div><br></div><div>// Foreign.php<br></div><div><b=
r></div><div>class Foreign {<br></div><div>&nbsp; public function __cons=
truct(public string $name) {}<br></div><div>}<br></div><div><br></div><d=
iv>// My code:<br></div><div><br></div><div>$f =3D new Foreign('beep');<=
br></div><div>$rProp =3D (new ReflectionObject($f))-&gt;getProperty('nam=
e');<br></div><div>if ($rProp-&gt;isPublic()) {<br></div><div>&nbsp; $f-=
&gt;name =3D 'boop';<br></div><div>}<br></div><div><br></div><div>Under =
PHP 8.0, this code works.<br></div><div>Upgrading to PHP 8.1, this code =
*still works* exactly the same.&nbsp; Therefore, there is no BC break.<b=
r></div><div>Upgrading to PHP 8.4, this code *still works* exactly the s=
ame.&nbsp; Therefore, there is no BC break.<br></div><div><br></div><div=
>Now, someone edits Foreign.php in 8.1 to read:<br></div><div><br></div>=
<div>class Foreign {<br></div><div>&nbsp; public function __construct(pu=
blic readonly string $name) {}<br></div><div>}<br></div><div><br></div><=
div>Now, my code will fail, because isPublic() does not guarantee "is wr=
iteable" anymore.&nbsp;&nbsp;<br></div><div><br></div><div>Is this a BC =
break in PHP?<br></div><div><br></div><div>I can see the argument either=
 way, personally, but I tend toward no.&nbsp; One PHP version to the nex=
t should always be safe to upgrade an *existing* code base.&nbsp; Just s=
wap out the PHP binary and it should still work the same.&nbsp; We want =
that.&nbsp; However, once you start modifying any part of the code (incl=
uding dependencies), all bets are off.<br></div><div><br></div><div>Supp=
ose some library switched from using annotations to using attributes.&nb=
sp; 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.&nbsp; Or ancient PHP 4 code that just assumed all properties were p=
ublic (which they were in PHP 4), now confronted with PHP 5 code that ha=
s private properties.&nbsp; Is that a PHP BC break?&nbsp; Not at all.<br=
></div><div><br></div><div>And again, the relevant change here happened =
in PHP 8.1.&nbsp; This is only tangentially related to 8.4 at all, becau=
se isPublic() has not implicitly meant is-writeable anymore for three ye=
ars.<br></div><div><br></div><div>--Larry Garfield<br></div><div><br></d=
iv></blockquote><div><br></div><div>Hey Larry,<br></div><div><br></div><=
div>First, thank you for this feature. Second, attributes and annotation=
s are a moot point. Adding attributes didn't render annotations broken a=
nd is still (unfortunately) used today in many codebases running 8.3. So=
, in other words, the deprecation of annotations is a framework/codebase=
/user-level issue and totally unrelated to attributes and PHP as a langu=
age. While attributes helped with that deprecation, it wasn't caused by =
them=E2=80=94people could have deprecated annotations without ever havin=
g attributes.<br></div><div><br></div><div>According to Wikipedia (<a hr=
ef=3D"https://en.wikipedia.org/wiki/Backward_compatibility">https://en.w=
ikipedia.org/wiki/Backward_compatibility</a>)<br></div><div><br></div><b=
lockquote type=3D"cite"><div><span class=3D"color" style=3D"color:rgb(32=
, 33, 34);">In&nbsp;</span><a href=3D"https://en.wikipedia.org/wiki/Comp=
iler">compilers</a><span class=3D"color" style=3D"color:rgb(32, 33, 34);=
">, [and interpreters] backward compatibility may refer to the ability o=
f a compiler [or interpreter] for a newer version of the language to acc=
ept source code of programs or data that worked under the previous versi=
on.</span><br></div></blockquote><div><br></div><div>I think this is all=
 we need: just a proper definition. Looking at the issue at play, we can=
 conclude that it isn't a BC break =E2=80=94 code that worked in 8.3 wil=
l continue to work in 8.4. Will things have to be updated (or in my case=
, rewritten basically from scratch)? Sure! But there, it becomes a frame=
work/codebase/user-level issue on whether they will remain backwards com=
patible with older versions of PHP.<br></div><div><br></div><div id=3D"s=
ig121229152">=E2=80=94 Rob<br></div></body></html>
--1dca82df820e46e491b130010a09720b--