Am 14.01.2020 um 20:23 schrieb Mike Schinkel <m...@newclarity.net>:
>
> On Jan 14, 2020, at 1:10 PM, Larry Garfield <la...@garfieldtech.com> wrote:
>>> I get your concern about recursion, but if that kind of issue is really
>>> a concern I don't see why we could not artificially limit recursion on
>>> 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 the
>> code changes between preload and non-preload contexts in subtle, non-obvious
>> 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 preloaded. So
>> whether or not foo.php was run through opcache_compile_file() changes when
>> and how code in that file will fail. That's the situation we want to avoid
>> like the plague, IMO.
>
> With respect, that feels like you are concerned about some real edge cases,
> and ignoring the probability that most code run during preloading would be
> written bespoke for preloading.
>
> ALSO, I think I may have caused confusion by calling it "preloading." In my
> mind that meant "run once" vs. "run for each page load" but I think you are
> (rightly) conflating what I have called "preloading" with the new preloading
> feature in PHP 7.4?
>
> What I have been envisioning is a `preload` (or some other) keyword that we
> could apply to functions, methods, and expressions. When `preload` modified
> functions/methods/expressions are reached during OpCode generation, rather
> than generate a call to runtime code PHP would just run the code and then
> take the return value and generate OpCode for that return value.
>
> class Foo {
> preload function bar() {
> return < a_really_time_consuming_expression>;
> }
> }
> $foo = new Foo();
> echo $foo->bar(); // This would not actually execute anything at runtime.
> // It would simply echo the constant value that
> was
> // returned by
> <a_really_time_consuming_expression>.
>
So like this old memoize extension? https://pecl.php.net/package/memoize
>
> I could be wrong but I find it hard to believe the runtime profile would be
> so different in this context as to create problems of the nature you are
> fearing.
>
> Maybe someone like Dimitry who understand the OpCode generation process could
> weigh in?
>
>
>>> I do completely see your points about the AST and most PHP developers.
>>>
>>> The unfortunate problem with PHP is there is no way to use 3rd party
>>> code to extend PHP w/o being able to reconfigure the server by adding
>>> extensions. It would be nice if we could come up with a way for 3rd
>>> party developers writing in C or another language — people who are more
>>> likely to test their code before distributing it — to extend PHP such
>>> as by generating OpCode files that a userland developer could load.
>>
>> That... sounds a lot like the new FFI extension? Write code in C or Rust or
>> anything that can produce a .so file, plug it into PHP, go?
>
> Unless I am misunderstanding, using an .so requires a sysadmin to add an
> extension and update php.ini. Which is a non-starter on hosted sites like
> Pantheon, WPEngine, Kinsta, Pagely, Flywheel, PressLabs and similar.
>
> What I was instead calling for what a way to extend PHP that a userland
> developer with no access to php.ini would be able to achieve.
>
> Interestingly, after my above comment I googled and came across this PHP
> extension that can load a compiled Web Assembly (.wasm) file. Something like
> this in core would be very useful:
>
> https://github.com/wasmerio/php-ext-wasm
>
> -Mike
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
