On Fri, Oct 19, 2018 at 3:17 AM Dmitry Stogov <dmi...@zend.com> wrote:
> I would like to start discussion on a Preloadng RFC
> https://wiki.php.net/rfc/preload
>
Overall, big +1.
A few questions:
1) "Only classes without unresolved parent, interfaces, traits and
constant values may be preloaded." Is this determined at the moment of
an individual opcache_compile_file()? Or can mis-ordered includes
resolve themselves upon later compiles? e.g. I compile a.php with
`class A extends B {}`, then subsequently compile b.php with `class B
{}`. The engine has enough information to resolve this, even if it
wasn't presented in an ideal order.
2) Will we raise warnings explaining why a given class is being
deferred from pre-loading to help users understand how to use this
correctly?
3) "Preloading may be used as systemlib in HHVM to define “standard”
functions/classes in PHP" Presumably the internal APIs will be defined
to handle this at the script level already. What stops us from simply
ZENDAPIing the proto and letting extensions call it if they want?
((Simple conservatism is an adequate answer, but I'd like to know why
it's out of scope)).
4) "In conjunction with ext/FFI (dangerous extension), we may allow
FFI functionality only in preloaded PHP files, but not in regular
ones." Is there any interest in something like HHVM's HNI interface?
FFI always sounds nice in theory, but complex types mean that a little
bit of glue code is often a plus.
> I'll try to fix this in nearest week(s).
>
Thank you for everything you do.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
