rfc:remove_zend_api
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:remove_zend_api [2009/03/29 01:58] – Fill out solution and example pbiggar | rfc:remove_zend_api [2009/04/04 19:27] – missed a link pbiggar | ||
---|---|---|---|
Line 3: | Line 3: | ||
* Date: 2009-03-27 | * Date: 2009-03-27 | ||
* Author: Paul Biggar < | * Author: Paul Biggar < | ||
- | * Status: | + | * Status: |
Line 10: | Line 10: | ||
===== Introduction ===== | ===== Introduction ===== | ||
- | ** Naturally, this seems insane. Please bear with me. ** | + | This is an ongoing RFC to design a new "PHP native interface" |
Line 27: | Line 27: | ||
The main problem with it is that it constrains the implementation of the Zend Engine. The Zend API creates a tight coupling between the ZendEngine and its users, restricting greatly our ability to change the Zend Engine. By requiring backwards compatability with the Zend Engine, we are ensuring that the ZendEngine can only be modified in minor ways (although ABI changes are allowed for major versions). This holds the Zend Engine to design decisions made nearly 10 years ago, and prevent PHP from getting much faster in the long term. | The main problem with it is that it constrains the implementation of the Zend Engine. The Zend API creates a tight coupling between the ZendEngine and its users, restricting greatly our ability to change the Zend Engine. By requiring backwards compatability with the Zend Engine, we are ensuring that the ZendEngine can only be modified in minor ways (although ABI changes are allowed for major versions). This holds the Zend Engine to design decisions made nearly 10 years ago, and prevent PHP from getting much faster in the long term. | ||
- | The Zend API also makes it difficult to write PHP extensions. Although most of the API is not terribly difficult to work with, concepts like copy-on-write, | + | The Zend API also makes it difficult to write PHP extensions. Although most of the API is not terribly difficult to work with, concepts like copy-on-write, |
A number of other PHP implementations exist, such as IBM's Project Zero, Phalanger, Roadsend, Quercus and phc. Many of these projects find it very difficult to re-use PHP's standard libraries. Quercus and Roadsend have reimplemented popular standard libraries. Phalanger and Project Zero attempt to re-use the existing libraries by marshalling their data into the Zend API. This appears to be slow and error-prone. phc is designed around reusing the Zend API for compatibility with the PHP. This constrains many of the optimizations phc would wish to perform, since it uses the Zend API nearly everywhere. | A number of other PHP implementations exist, such as IBM's Project Zero, Phalanger, Roadsend, Quercus and phc. Many of these projects find it very difficult to re-use PHP's standard libraries. Quercus and Roadsend have reimplemented popular standard libraries. Phalanger and Project Zero attempt to re-use the existing libraries by marshalling their data into the Zend API. This appears to be slow and error-prone. phc is designed around reusing the Zend API for compatibility with the PHP. This constrains many of the optimizations phc would wish to perform, since it uses the Zend API nearly everywhere. | ||
Line 45: | Line 45: | ||
Take the use case of wrapping a C library to expose its functionality in user space. The major idea is to " | Take the use case of wrapping a C library to expose its functionality in user space. The major idea is to " | ||
- | Lets take a simple example | + | Lets take a simple example. Assume we have a C library XXX, with 3 functions, x, y and z. We'd like to expose this in user space as a class called MyXXX, with methods a and b. We create a file with the signatures of x, y and z: |
- | xxx/sigs.h | + | extensions/xxx/sigs.h |
+ | < | ||
int x (int, int); | int x (int, int); | ||
void y (char*, int); | void y (char*, int); | ||
void z (char*, int); | void z (char*, int); | ||
+ | </ | ||
We then write our user space code: | We then write our user space code: | ||
- | xxx/ | + | extensions/xxx/ |
+ | < | ||
class MyXXX | class MyXXX | ||
{ | { | ||
Line 75: | Line 78: | ||
} | } | ||
} | } | ||
+ | </ | ||
+ | In order to interface between these two, it will be necessary to have a tool to automatically wrap the C functions. SWIG could be used to create this tool. | ||
+ | === Zend engine === | ||
+ | Since the libraries would no longer use the Zend API, the tight coupling would be broken. It would now be possible to change major parts of the Zend engine without affecting the operation of any other part of PHP. | ||
+ | |||
+ | === Extensions/ | ||
+ | |||
+ | It would no longer be necessary to know the Zend API to write extensions. Instead, only the API of the C library is necessary, and the interface can be created in PHP user code. | ||
+ | |||
+ | === Embed SAPI === | ||
+ | |||
+ | The same interface used for libraries can be used to handle many of the use cases of the C API. However, it is likely that a means to call PHP user code from C/C++ code, will be required. | ||
+ | |||
+ | |||
+ | === Other PHP implementations === | ||
+ | |||
+ | Since PHP extensions are no longer written in the Zend API, other PHP implementations, | ||
+ | |||
+ | |||
+ | ===== Similar projects ===== | ||
+ | |||
+ | === Non-PHP === | ||
+ | |||
+ | phpni differs from many of these in that it is designed not to add new features, but instead to replace an existing facility - the ability to call C libraries. As such, dynamic linking is not part of the spec. | ||
+ | |||
+ | * ctypes (Python) http:// | ||
+ | * JNI (Java) http:// | ||
+ | * CNI (Java) http:// | ||
+ | * JNA (Java) https:// | ||
+ | * Pyrex (Python) http:// | ||
+ | * Cython (Python) http:// | ||
+ | * FFI (ruby) http:// | ||
+ | * Haskell 98 Foreign Function Interface http:// | ||
+ | * CFFI (Common Lisp): Common-Lisp FFI: http:// | ||
+ | |||
+ | === For PHP === | ||
+ | |||
+ | There is no reason we shouldn' | ||
+ | |||
+ | * FFI http:// | ||
+ | * CodeGen_PECL http:// | ||
+ | * Inline_C http:// | ||
+ | | ||
===== Project Plan ===== | ===== Project Plan ===== | ||
- | This is a simple design. In reality, it would need to be prototyped to determine | + | This is a simple design. In reality, it would need to be prototyped to determine |
+ | * Prototype a single library | ||
+ | * perhaps readline? | ||
+ | * Manually write interface code between the header and the PHP code. | ||
- | ==== Links ==== | + | * Discuss requirements with other PHP implementations |
+ | |||
+ | * Write a utility to generate the interface code automatically | ||
+ | * Using SWIG? | ||
+ | * Test 5 or 6 libraries | ||
+ | * Test more complicated functionality | ||
+ | * Convert entire set of PHP extensions | ||
- | ===== Changelog ===== | + | Naturally, before the last step it will be necessary to get consensus from other internals developers that this is a good idea. It would be worthwhile to produce a document discussing the experience so far. |
rfc/remove_zend_api.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1