Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125783
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 11 Oct 2024 10:31:51 +0200
To: "Valentin Udaltsov" <udaltsov.valentin@gmail.com>,
 "Claude Pache" <claude.pache@gmail.com>
Cc: "php internals" <internals@lists.php.net>
Message-ID: <e966cf16-794d-4827-9a5e-b0de780a5b91@app.fastmail.com>
In-Reply-To: 
 <CAPyeZ4MSc=Sw9UE0soCdBEnVAJ8wXHHhYqm88OffkvNLrHPxFw@mail.gmail.com>
References: 
 <CAPyeZ4N8GMiLNVCDGxdofcy6txBhng_i2UKUGpiS5bnZ-YcYvA@mail.gmail.com>
 <2A7CF24F-3AE3-4125-965F-C65431C42DFB@gmail.com>
 <CAPyeZ4MSc=Sw9UE0soCdBEnVAJ8wXHHhYqm88OffkvNLrHPxFw@mail.gmail.com>
Subject: Re: [PHP-DEV] Asymmetric visibility is a BC break
Content-Type: multipart/alternative;
 boundary=470986bcfd4347f5a5bb119929185864
From: rob@bottled.codes ("Rob Landers")

--470986bcfd4347f5a5bb119929185864
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 10, 2024, at 15:32, Valentin Udaltsov wrote:
> On 09.102024=E2=80=AFat 19:20 Claude Pache <claude.pache@gmail.com> wr=
ote:
> > There is no BC break, in the sense that code that worked under PHP 8=
.3 (and therefore use PHP 8.3 features only) will not break when run und=
er PHP 8.4.
> >
> > Of course, code that makes assumptions that are true when using PHP =
8.3 features only, will need to be adapted as soon as PHP 8.4 features a=
re used. This is unsurprising and expected.
>=20
> Hi, Claude!
>=20
> Thank you for the explanation. I now get why aviz does not break BC :)
> Until now, I was worried that we were missing something important.
>=20
> > That said, https://github.com/php/php-src/pull/16209 is interesting =
to have, but not mandatory. The current `ReflectionProperty::isPropertyS=
et()` and `ReflectionProperty::isPrivateSet()` might be somewhat confusi=
ng at first, but they are sufficient in order to obtain the needed infor=
mation.
>=20
> Yes, they are sufficient, but very difficult to work with. Just to
> check that property is writable from global scope, you have to do
> `isPublic() && !isReadonly() && !isPrivateSet() && !isProtectedSet()
> && (!isVirtual() || hasHook(PropertyHookType::Set))`.
> See our discussion with Ilija:
> https://github.com/php/php-src/issues/16175#issuecomment-2389966021
>=20
> --
> Valentin
>=20

Hello all,

I am still struggling to understand how this isn't a BC break when it mo=
st obviously is. Sure, code that worked on 8.3 will continue to work on =
8.4. In that case, we could have argued that my function autoloading RFC=
 didn't have a BC break, because proper implementations wouldn't have br=
oken. To me, this is along the same lines. A "proper" implementation won=
't break, but there may be subtle ways that "improper" implementations w=
ill break and thus it should be considered a BC break.

=E2=80=94 Rob
--470986bcfd4347f5a5bb119929185864
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 Thu, Oct 10,=
 2024, at 15:32, Valentin Udaltsov wrote:<br></div><blockquote type=3D"c=
ite" id=3D"qt" style=3D""><div>On 09.102024=E2=80=AFat 19:20 Claude Pach=
e &lt;<a href=3D"mailto:claude.pache@gmail.com">claude.pache@gmail.com</=
a>&gt; wrote:<br></div><div>&gt; There is no BC break, in the sense that=
 code that worked under PHP 8.3 (and therefore use PHP 8.3 features only=
) will not break when run under PHP 8.4.<br></div><div>&gt;<br></div><di=
v>&gt; Of course, code that makes assumptions that are true when using P=
HP 8.3 features only, will need to be adapted as soon as PHP 8.4 feature=
s are used. This is unsurprising and expected.<br></div><div><br></div><=
div>Hi, Claude!<br></div><div><br></div><div>Thank you for the explanati=
on. I now get why aviz does not break BC :)<br></div><div>Until now, I w=
as worried that we were missing something important.<br></div><div><br><=
/div><div>&gt; That said,&nbsp;<a href=3D"https://github.com/php/php-src=
/pull/16209">https://github.com/php/php-src/pull/16209</a> is interestin=
g to have, but not mandatory. The current `ReflectionProperty::isPropert=
ySet()` and `ReflectionProperty::isPrivateSet()` might be somewhat confu=
sing at first, but they are sufficient in order to obtain the needed inf=
ormation.<br></div><div><br></div><div>Yes, they are sufficient, but ver=
y difficult to work with. Just to<br></div><div>check that property is w=
ritable from global scope, you have to do<br></div><div>`isPublic() &amp=
;&amp; !isReadonly() &amp;&amp; !isPrivateSet() &amp;&amp; !isProtectedS=
et()<br></div><div>&amp;&amp; (!isVirtual() || hasHook(PropertyHookType:=
:Set))`.<br></div><div>See our discussion with Ilija:<br></div><div><a h=
ref=3D"https://github.com/php/php-src/issues/16175#issuecomment-23899660=
21">https://github.com/php/php-src/issues/16175#issuecomment-2389966021<=
/a><br></div><div><br></div><div>--<br></div><div>Valentin<br></div><div=
><br></div></blockquote><div><br></div><div>Hello all,<br></div><div><br=
></div><div>I am still struggling to understand how this isn't a BC brea=
k when it most obviously is. Sure, code that worked on 8.3 will continue=
 to work on 8.4. In that case, we could have argued that my function aut=
oloading RFC didn't have a BC break, because proper implementations woul=
dn't have broken. To me, this is along the same lines. A "proper" implem=
entation won't break, but there may be subtle ways that "improper" imple=
mentations will break and thus it should be considered a BC break.<br></=
div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob<br></div></bod=
y></html>
--470986bcfd4347f5a5bb119929185864--