Hi Nikita,
Le 06/06/2017 à 14:43, Nikita Popov a écrit :
Anyway, to get back to the topic of PCS. First, I would recommend to
target PHP 7.3 for this change. Feature freeze for 7.2 is in a bit
over a month and I think we'll want to make some non-trivial changes
to how this works if we integrate it in PHP. If added to PHP, I think
this should be integrated into the core, rather than being an extension.
Agreed. My initial choice was to keep it as a separate extension. This
was fine for a proof of concept but we cannot solve the points raised
below without a tighter integration with the core. I would have liked to
keep the coupling as loose as possible but solving the remaining issues
is more important. So, let's consider 7.3 as the new target.
1. As far as I understand, PCS relies on autoloading. There are two
issues here: First, autoloading does not register symbols prior to
autoloading. This means that functions like get_defined_classes() will
not behave as expected. Second, autoloading does not support
functions. I think both of these problems can be solved with some
up-front symbol analysis. Lazily compiling internal functions should
not run into any of the problems we have with userland function
autoloading.
Right. PCS implements a workaround by loading the code containing
functions at the beginning of each request. So, my plan was a future
extension of the autoloading mechanism to functions (and constants).
The PCS autoloader already extracts symbols from the PHP code at
registration time. So, PCS already has a list of the class, function,
and constant names it manages. I don't know what you mean with 'Lazily
compiling internal functions'. Autoloading, combined with opcache,
avoids to execute the whole code at the beginning of each request but
there are probably better alternatives.
2. It has already been mentioned in the thread, but what seems to lack
right now is a good way of integrating PHP and C portions. As far as I
understand, PCS allows you to write an entire class in PHP, but it
does not allow you to offload parts of the functionality to C without
exposing additional public APIs. I think there are two things we can
do here:
a) Provide a mechanism that makes certain functions only available
inside extension PHP code. This would allow exposing some private PHP
functions which are only used in the internal implementation of the
extension.
b) Allow binding some methods specified in PHP to an internal
implementation. The way this works in HHVM is that the PHP file
contains just a signature, with an attribute that signifies that an
internal implementation will be bound to that function:
class Bar {
<<__Native>>
function foo($args);
}
This would be useful for other reasons as well. In particular, this
could become a replacement for the existing arginfo-based signature
specification, which is somewhat limited and causes discrepancies with
userland classes. For example, arginfo does not support default values.
Implementing this may be beyond my capacity but, if you agree, we can
work together to implement solutions to these issues. Other volunteers
are welcome too.
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
