Embedding PHP code in PHP extensions

Projects - Ideas
Print
Read : 44,970 times
(0 votes, average 0 out of 5)



Traditionnally, PHP extensions contain C code only. The main reason is obvious : this code needs to be fast and access external C APIs. But, in many cases, some parts of the extension code could be written in PHP.

Some use cases, extracted from the discussion referenced below :

What came out from the discussion is that different use cases require two different ways to relate extensions with PHP code :

The mechanism we propose here allows both options.

Here are the main issues we must solve :

Proposal

I propose to implement an extension that would provide a service to other extensions. The interaction between this 'service' and 'client' extensions would be reduced to this : at MINIT time, each client extension registers the PHP code it wants to make available. This code may come from the extension code itself or from an external file that will be read and stored in persistent memory. File trees can be recursively registered too. The client extension also provides a virtual path which will be used to store and retrieve the corresponding PHP script.

After the MINIT phase, if the client extension needs to access or reference one of these PHP scripts, it will do it through this virtual path, using a common stream wrapper.

Each time the service extension receives a PHP script to register, it scans the PHP code to extracts the class names this code defines, and registers these names in an autoload map. Then, during a request, when one of these names is referenced, the corresponding script is autoloaded. By using the autoloader, we eliminate the need to execute the whole PHP code in every request. All these features (symbol extraction + autoloading) will use the Automap autoloader.

:note Today, using the autoloader allows to load classes only but, if this mechanism proves useful, autoloading can easily be extended to functions and constants. The only reason why it was not done earlier is that most people didn't see any valid use case. This may be one.

The opcache issue is slighly more complex because the current opcache code only allows the 'file:' and 'phar:' stream wrappers to be cached. This issue goes beyond this specific case. It will be solved by a future additional 'cache_key' stream operation, which will open opcode caching to every stream wrappers.

References

 
Joomla SEO powered by JoomSEF