Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126024
Feedback-ID: id5114917:Fastmail
Date: Thu, 21 Nov 2024 12:46:08 +0000
To: internals@lists.php.net
Subject: Re: [PHP-DEV] opcache_compile_file() declares top-level functions
User-Agent: K-9 Mail for Android
In-Reply-To: <EFC142CD-4F80-429A-BE5B-9624B493BD08@gmail.com>
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>
Message-ID: <71304D27-1884-4D7B-B3B5-5E5DB753F216@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 21 November 2024 10:48:46 GMT, Daniil Gentili <daniil=2Egentili@gmail=
=2Ecom> wrote:
>I speak for myself (and some others, as can be seen by pull requests on s=
ome FOSS projects, which made pull requests to account for this behaviour),=
 as a user of preloading who has encountered this behaviour, understood the=
 reason for it and made the required changes to keep using it=2E

This is still painfully vague=2E What projects? What "reason for it" did y=
ou understand? When you say projects accounted for it, do you mean they got=
 some benefit from it, or that they worked around the problems it caused th=
em?


>There is indeed nothing wrong with the listed behaviours IMO, as they mak=
e sense for how the current logic is working, and aren=E2=80=99t a deal bre=
aker for preloading=2E

This seems to be entirely circular - "the current behaviour makes sense fo=
r the current behaviour"=2E


>In fact preloading in a way behaves as if you included the preload file b=
efore including the entry point

Note that we are not talking about preloading, as a general concept; we ar=
e talking about the specific function opcache_compile_file=2E That function=
's explicit purpose is to prime the opcache *without* behaving the same way=
 as including the file=2E=20


> functions cannot be declared twice, and already-declared classes are not=
 autoloaded again

Finally, we seem to get to the use case you are actually advocating: preco=
mpiling classes but using an autoloader to actually declare them; but fully=
 pre-declaring functions, because there's no autoloader for them=2E

That certainly makes sense as a distinction, but I then wonder why you wou=
ld use opcache_compile_file for declaring those functions, rather than a no=
rmal include=2E Since you can't include the file a second time either way, =
is there any way to make use of the difference?


> it might be a nice idea to simply ignore the redeclaration of functions =
(like for classes), instead of not preloading them at all=2E


There is nothing that ignores the redeclaration of classes; they are not d=
eclared when pre-compiling, and can be declared exactly once by passing inc=
lude/require the pre-compiled file=2E Making functions match that behaviour=
 is what Ilija is proposing=2E


Rowan Tommins
[IMSoP]