Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108136
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <a599c53d-665b-4e45-9d3e-c5deeac2d5f4@www.fastmail.com>
Date: Tue, 14 Jan 2020 20:57:38 -0500
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <90DE6E75-813C-4372-A8B7-799ADF74CEDE@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>
 <2502e68d-a1bc-41c6-9763-8c0e2ac9e6f4@www.fastmail.com>
 <A053F3BB-97CC-4CB3-99DE-275438628E8C@newclarity.net>
 <a599c53d-665b-4e45-9d3e-c5deeac2d5f4@www.fastmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Subject: Re: [PHP-DEV] Introducing compile time code execution to PHP
 preloading
From: mike@newclarity.net (Mike Schinkel)

> On Jan 14, 2020, at 7:50 PM, Larry Garfield <larry@garfieldtech.com> =
wrote:
> I think you're still missing my point here.  AST manipulation during =
preload would exist to manipulate code that would be run *later*.  =
That's the point.  Sure, the code in the run_once/preload/whatever block =
would be written to run in that context, but its entire point is, =
presumably, to improve the running of the *rest* of the code later.

And respectfully, I think I am not missing your point but that possibly =
you are misunderstand what I was proposing.

I was not proposing *any* AST manipulation, at least not for what I was =
defining as "Userland Preloading."   Unless you define AST manipulation =
as using PHP to generate code to insert literals into OpCode, but if so =
I think that would be disingenuous.)

If you remember I said this thread had gotten to the point I am seeing =
these separate issues that should probably be three separate threads, =
which I will repeat here:

1. Userland preloading
2. Userland loadable extensions
3. Projection API and related

None of the above manipulate the AST directly, although #3 would do so =
indirectly.  (There is an argument to be made that we could split #3 =
into higher level APIs and lower level AST manipulation which, IMO, =
should be two different debates, for a total of at least 4 different =
debates here.)

So again, when I am proposing userland preloading I am *not* as part of =
that proposal proposing AST manipulation, although I believe Robert =
Hickman may have been and maybe I should start a different thread?

That is why I find it hard to believe that PHP would generate code that =
would fail when PHP runs that code.

> That... is a completely different thing, yes, that has nothing to do =
with the PHP 7.4 feature called preloading.  Which would mean we've been =
talking about two different things this whole damned time.  *sigh*

Yes.  And I will take the blame for that.  It did not occur to me until =
Robert mentioned to me that it was confusing.

> No, the whole point of the FFI extension is that a user-land developer =
can load a .so file into PHP directly; basically doing the lib->PHP glue =
code in PHP rather than in C.  It does require the FFI extension itself =
to be enabled, and to do safely requires using the preloader, which does =
mean setting an ini setting.

Interesting.  So then maybe what I an asking for is to bundle FFI into =
core so that it is available everywhere.

> Not all hosts support that.  The one I work for does, which is why =
I've been playing with it lately to document it all for our customers. =
:-)  But the fact that such advanced features are not universally =
available is... exactly why I am extremely cautious about having =
functionality that results in subtle behavioral differences between =
those environments where it's available and those where it's not.

Another interesting option would be to enable loading and running of =
WebAssembly in core.  Do you have a position on that?

> The existing preload logic has no impact on behavior other than =
skipping the autoloader.  Any behavioral change is limited to those =
oddball libraries that do black magic during the autoloader, which are =
already well off the beaten path.  That makes it a "safe" optimization.

So basically, I think this is what I have been asking for, but userland =
accessible. =20

I would envision that if it modified any environment, such as setting a =
preloaded or error levels etc. then all that environment would reset =
during normal execution.

> My underlying point, and then I will bow out of this thread as I am =
tired of repeating myself, is that I am all for enabling more "safe" =
optimizations, even letting userland developers build them, but we need =
to be extremely careful about them being "safe" and not "a time bomb =
that will introduce subtle behavioral differences between different run =
modes that a developer is not expecting,thus slowly creating libraries =
that will only function in one run mode or the other".

I appreciate and agree with the desire not to have unsafe issues. But as =
I have felt we were talking about two different things and you confirmed =
that, maybe what I have actually been proposing is not something we need =
to be at odds about?

-Mike=