Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126026
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 21 Nov 2024 15:17:01 +0100
To: internals@lists.php.net
Message-ID: <4becf27f-2de1-4c74-9cf0-7dbff7bebf6c@app.fastmail.com>
In-Reply-To: <71304D27-1884-4D7B-B3B5-5E5DB753F216@rwec.co.uk>
References: 
 <CAPyj-LD+X-XZoc5kZmW2qTCuu1-q5NtqEZyZhEs0rhvXa2AyJg@mail.gmail.com>
 <A4F812D1-2C6F-4621-A663-3B98A5F6C8E1@gmail.com>
 <09E90996-133F-47FD-878F-5D1F7A99A3ED@rwec.co.uk>
 <EFC142CD-4F80-429A-BE5B-9624B493BD08@gmail.com>
 <71304D27-1884-4D7B-B3B5-5E5DB753F216@rwec.co.uk>
Subject: Re: [PHP-DEV] opcache_compile_file() declares top-level functions
Content-Type: multipart/alternative;
 boundary=fb6c3c90192947a1a13452ea3a906e70
From: rob@bottled.codes ("Rob Landers")

--fb6c3c90192947a1a13452ea3a906e70
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 21, 2024, at 13:46, Rowan Tommins [IMSoP] wrote:
>=20
>=20
> On 21 November 2024 10:48:46 GMT, Daniil Gentili <daniil.gentili@gmail=
.com> wrote:
> >I speak for myself (and some others, as can be seen by pull requests =
on some FOSS projects, which made pull requests to account for this beha=
viour), as a user of preloading who has encountered this behaviour, unde=
rstood the reason for it and made the required changes to keep using it.
>=20
> This is still painfully vague. What projects? What "reason for it" did=
 you understand? When you say projects accounted for it, do you mean the=
y got some benefit from it, or that they worked around the problems it c=
aused them?
>=20
>=20
> >There is indeed nothing wrong with the listed behaviours IMO, as they=
 make sense for how the current logic is working, and aren=E2=80=99t a d=
eal breaker for preloading.
>=20
> This seems to be entirely circular - "the current behaviour makes sens=
e for the current behaviour".
>=20
>=20
> >In fact preloading in a way behaves as if you included the preload fi=
le before including the entry point
>=20
> Note that we are not talking about preloading, as a general concept; w=
e are talking about the specific function opcache_compile_file. That fun=
ction's explicit purpose is to prime the opcache *without* behaving the =
same way as including the file.=20
>=20
>=20
> > functions cannot be declared twice, and already-declared classes are=
 not autoloaded again
>=20
> Finally, we seem to get to the use case you are actually advocating: p=
recompiling classes but using an autoloader to actually declare them; bu=
t fully pre-declaring functions, because there's no autoloader for them.
>=20
> That certainly makes sense as a distinction, but I then wonder why you=
 would use opcache_compile_file for declaring those functions, rather th=
an a normal include. Since you can't include the file a second time eith=
er way, is there any way to make use of the difference?
>=20
>=20
> > it might be a nice idea to simply ignore the redeclaration of functi=
ons (like for classes), instead of not preloading them at all.
>=20
>=20
> There is nothing that ignores the redeclaration of classes; they are n=
ot declared when pre-compiling, and can be declared exactly once by pass=
ing include/require the pre-compiled file. Making functions match that b=
ehaviour is what Ilija is proposing.
>=20
>=20
> Rowan Tommins
> [IMSoP]
>=20

Seems like function autoloading would alleviate this use case and make t=
his behavior easier to deprecate.

=E2=80=94 Rob
--fb6c3c90192947a1a13452ea3a906e70
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, Nov 21,=
 2024, at 13:46, Rowan Tommins [IMSoP] wrote:<br></div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div><br></div><div><br></div><div>On 21 Nov=
ember 2024 10:48:46 GMT, Daniil Gentili &lt;<a href=3D"mailto:daniil.gen=
tili@gmail.com">daniil.gentili@gmail.com</a>&gt; wrote:<br></div><div>&g=
t;I speak for myself (and some others, as can be seen by pull requests o=
n some FOSS projects, which made pull requests to account for this behav=
iour), as a user of preloading who has encountered this behaviour, under=
stood the reason for it and made the required changes to keep using it.<=
br></div><div><br></div><div>This is still painfully vague. What project=
s? What "reason for it" did you understand? When you say projects accoun=
ted for it, do you mean they got some benefit from it, or that they work=
ed around the problems it caused them?<br></div><div><br></div><div><br>=
</div><div>&gt;There is indeed nothing wrong with the listed behaviours =
IMO, as they make sense for how the current logic is working, and aren=E2=
=80=99t a deal breaker for preloading.<br></div><div><br></div><div>This=
 seems to be entirely circular - "the current behaviour makes sense for =
the current behaviour".<br></div><div><br></div><div><br></div><div>&gt;=
In fact preloading in a way behaves as if you included the preload file =
before including the entry point<br></div><div><br></div><div>Note that =
we are not talking about preloading, as a general concept; we are talkin=
g about the specific function opcache_compile_file. That function's expl=
icit purpose is to prime the opcache *without* behaving the same way as =
including the file.&nbsp;<br></div><div><br></div><div><br></div><div>&g=
t; functions cannot be declared twice, and already-declared classes are =
not autoloaded again<br></div><div><br></div><div>Finally, we seem to ge=
t to the use case you are actually advocating: precompiling classes but =
using an autoloader to actually declare them; but fully pre-declaring fu=
nctions, because there's no autoloader for them.<br></div><div><br></div=
><div>That certainly makes sense as a distinction, but I then wonder why=
 you would use opcache_compile_file for declaring those functions, rathe=
r than a normal include. Since you can't include the file a second time =
either way, is there any way to make use of the difference?<br></div><di=
v><br></div><div><br></div><div>&gt; it might be a nice idea to simply i=
gnore the redeclaration of functions (like for classes), instead of not =
preloading them at all.<br></div><div><br></div><div><br></div><div>Ther=
e is nothing that ignores the redeclaration of classes; they are not dec=
lared when pre-compiling, and can be declared exactly once by passing in=
clude/require the pre-compiled file. Making functions match that behavio=
ur is what Ilija is proposing.<br></div><div><br></div><div><br></div><d=
iv>Rowan Tommins<br></div><div>[IMSoP]<br></div><div><br></div></blockqu=
ote><div><br></div><div>Seems like function autoloading would alleviate =
this use case and make this behavior easier to deprecate.</div><div><br>=
</div><div id=3D"sig121229152">=E2=80=94 Rob<br></div></body></html>
--fb6c3c90192947a1a13452ea3a906e70--