Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125038
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 18 Aug 2024 00:48:37 +0200
To: internals@lists.php.net
Message-ID: <cdb920bd-0e35-4275-ab67-1fc97fd29e45@app.fastmail.com>
In-Reply-To: <CEDA81D5-50B5-48D5-8412-5062709EEF4F@rwec.co.uk>
References: <a897e9e9-dcc7-47f9-86db-c3c15294046a@app.fastmail.com>
 <94259551-80EE-41F4-9CF9-679B79B5EA49@koalephant.com>
 <c7782917-55ce-4d5b-bfad-2048d9a0af2d@app.fastmail.com>
 <CEDA81D5-50B5-48D5-8412-5062709EEF4F@rwec.co.uk>
Subject: Re: [PHP-DEV] function autoloading v4 RFC
Content-Type: multipart/alternative;
 boundary=5c383f566ce147df80d31ed304eaf268
From: rob@bottled.codes ("Rob Landers")

--5c383f566ce147df80d31ed304eaf268
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sun, Aug 18, 2024, at 00:40, Rowan Tommins [IMSoP] wrote:
>=20
>=20
> On 17 August 2024 22:33:03 BST, Rob Landers <rob@bottled.codes> wrote:
> >I wouldn't consider it a BC break, no. But (ironically?), Symfony cra=
shes with this change. It really shouldn't but ...
>=20
> I don't think it makes sense to say "it breaks existing code, but it's=
 not a compatibility break".
>=20
> Perhaps what you're saying is "it's only a BC break for code that's no=
t following best practices"?
>=20
> But more relevant than whether you think the current code is "correct"=
 is the fact that a) it will need to be changed to work with your propos=
al; and b) the change is simple and can be done in advance.=20
>=20
> So the RFC should acknowledge this BC break, but could argue that it's=
 small enough to include in a minor version. This is actually really com=
mon - RFCs that introduce a new global function often acknowledge that i=
t would break existing userland functions with that name. Between that a=
nd obviously serious BC breaks like *removing* a function, there's a big=
 grey area where we have to make a judgement call.
>=20
> Regards,
> Rowan Tommins
> [IMSoP]
>=20

Hey Rowan,

Ah, that's a good tip and point. Thank you. I'll update the RFC!

=E2=80=94 Rob
--5c383f566ce147df80d31ed304eaf268
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 Sun, Aug 18,=
 2024, at 00:40, Rowan Tommins [IMSoP] wrote:<br></div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div><br></div><div><br></div><div>On 17 Aug=
ust 2024 22:33:03 BST, Rob Landers &lt;<a href=3D"mailto:rob@bottled.cod=
es">rob@bottled.codes</a>&gt; wrote:<br></div><div>&gt;I wouldn't consid=
er it a BC break, no. But (ironically?), Symfony crashes with this chang=
e. It really shouldn't but ...<br></div><div><br></div><div>I don't thin=
k it makes sense to say "it breaks existing code, but it's not a compati=
bility break".<br></div><div><br></div><div>Perhaps what you're saying i=
s "it's only a BC break for code that's not following best practices"?<b=
r></div><div><br></div><div>But more relevant than whether you think the=
 current code is "correct" is the fact that a) it will need to be change=
d to work with your proposal; and b) the change is simple and can be don=
e in advance.&nbsp;<br></div><div><br></div><div>So the RFC should ackno=
wledge this BC break, but could argue that it's small enough to include =
in a minor version. This is actually really common - RFCs that introduce=
 a new global function often acknowledge that it would break existing us=
erland functions with that name. Between that and obviously serious BC b=
reaks like *removing* a function, there's a big grey area where we have =
to make a judgement call.<br></div><div><br></div><div>Regards,<br></div=
><div>Rowan Tommins<br></div><div>[IMSoP]<br></div><div><br></div></bloc=
kquote><div><br></div><div>Hey Rowan,</div><div><br></div><div>Ah, that'=
s a good tip and point. Thank you. I'll update the RFC!<br></div><div><b=
r></div><div id=3D"sig121229152">=E2=80=94 Rob<br></div></body></html>
--5c383f566ce147df80d31ed304eaf268--