Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108125
User-Agent: Cyrus-JMAP/3.1.7-754-g09d1619-fmstable-20200113v1
Mime-Version: 1.0
Message-ID: <2502e68d-a1bc-41c6-9763-8c0e2ac9e6f4@www.fastmail.com>
In-Reply-To: <FF6699B7-39E7-4AD7-8FC6-5EE02BBC8E05@newclarity.net>
References: 
 <CAMuFt-6=FaqRpTEvZDtW_OsLmq3R171nDc7wH0D5itJUosMtdQ@mail.gmail.com>
 <d2348c4b-7993-489e-86ed-01932a864ec9@www.fastmail.com>
 <CD056374-BE4F-4B7F-A0F1-5481D024AE8A@newclarity.net>
 <f0a08ad9-abfa-4155-941c-4efd2cf61842@www.fastmail.com>
 <FF6699B7-39E7-4AD7-8FC6-5EE02BBC8E05@newclarity.net>
Date: Tue, 14 Jan 2020 12:10:41 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: =?UTF-8?Q?Re:_[PHP-DEV]_Introducing_compile_time_code_execution_to_PHP_p?=
 =?UTF-8?Q?reloading?=
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Jan 13, 2020, at 1:26 PM, Mike Schinkel wrote:

> Thanks so much for going into such detail.  It really helped me=20
> understand your concerns.
>=20
> I have been planned to propose an alternate to `static_run` because it=
=20
> did not seem to me to be an ideal solution.  And my proposal would not=
=20
> have included modifying the AST per se, even though I think that could=
=20
> be beneficial. Instead it would just be focused on userland preloading=
=20
> (vs. system admin preloading.)
> IOW a preload feature that does not require restarting FPM but could=20=

> instead be controlled by the userland developer.

I defer to Dmitry on whether such a thing is reasonable.  My engine know=
ledge is far too paltry to comment.

> But before I introduce that I want to better understand why you think=20=

> having things that can only run during preload and having things that=20=

> can only run during runtime would be a bad thing.  To me it seems like=
=20
> a benefit.  Preload vs. runtime are two different contexts.  Having=20=

> different behavior for different contexts only makes sense IMO.  Look=20=

> at CLI vs. FPM contexts:
>=20
> - https://stackoverflow.com/a/25653068/102699

That's slightly different, as code will still execute in both contexts. =
 And most of those differences are related to how PHP interacts with the=
 outside world, in two different definitions of "outside world".

To illustrate my point, though... Well, that explains why my last attemp=
t to use STDOUT and STDERR in a non-CLI context failed without explanati=
on!  TIL...

> I get your concern about recursion, but if that kind of issue is reall=
y=20
> a concern I don't see why we could not artificially limit recursion on=
=20
> preload to a configurable amount, with 100 being the default?

It's not recursion itself that's an issue.  It's that the behavior of th=
e code changes between preload and non-preload contexts in subtle, non-o=
bvious ways.

I don't mean a recursive function that runs during preload.  I mean if a=
 function that runs in a normal request is written recursively, it will =
fail at high recursion levels only if the file it is in was not preloade=
d.  So whether or not foo.php was run through opcache_compile_file() cha=
nges when and how code in that file will fail.  That's the situation we =
want to avoid like the plague, IMO.

> Separately I think it would make sense to provide a set of APIs to do=20=

> the most commonly needed things that people might want to modify the=20=

> AST for.
>=20
> One example that I could envision that would make sense for preload bu=
t=20
> probably not for runtime is an extension of the Reflection API that=20=

> would allow code to define classes, interfaces, traits, functions, etc=
.=20
> Here is something I mocked up that I called "Projection" to illustrate=
=20
> that concept:
>=20
> - https://gist.github.com/mikeschinkel/e07eb14a34ce83a96198744e18b0c96=
1

I've seen similar concepts for code-generation libraries.  I've even wri=
tten a very basic one at one point.  That seems orthogonal to whether th=
e end result is writing the generated code to disk or compiling it direc=
tly into memory.  If we do make runtime code generation a first class ci=
tizen then some sort of API like that would be a good idea (as the alter=
native is to build a string and run eval()).

> --------------
>=20
> I do completely see your points about the AST and most PHP developers.=
 =20
>=20
> The unfortunate problem with PHP is there is no way to use 3rd party=20=

> code to extend PHP w/o being able to reconfigure the server by adding=20=

> extensions. It would be nice if we could come up with a way for 3rd=20=

> party developers writing in C or another language =E2=80=94 people who=
 are more=20
> likely to test their code before distributing it =E2=80=94 to extend P=
HP such=20
> as by generating OpCode files that a userland developer could load. =20=


That... sounds a lot like the new FFI extension?  Write code in C or Rus=
t or anything that can produce a .so file, plug it into PHP, go?

There's a whole lot of caveats on that, of course.  I'm working on a blo=
g post series on that very topic at work, so stay tuned if you're intere=
sted... :-)

--Larry Garfield