On Wed, Apr 1, 2009 at 3:35 PM, Andi Gutmans <a...@zend.com> wrote: > Hi Paul, > > This is something I have considered in the past esp. as it would also reduce > dependency of extensions on PHP runtime and make it easier for 3rd parties to > distribute PHP extensions which don't have to be rebuilt per-PHP version. > This is similar to JNI.
It is similar to JNI. This has been done many times before for many languages, including Pythons Pyrex and ctypes, Ruby's FFI, Java's JNI and JNA, and no doubt countless others. The only difference here is that I recommend that we made this the _only_ interface (or as close as we can make it) from the interpreter internals. > There are some real challenges though and JNI is a good example of those > challenges. In order to completely abstract the API from data structure you > need higher level API calls esp. for things like arrays and objects which > typically incur a significant performance loss. JNI sucks big time on that > front. Also it often leads to additional data copying. All of this happens at the moment to marshal data into zvals. My RFC does not intend to add to this complexity, but rather to make it work exactly the same as it does now. So if currently a library avoids copying values, it should be possible to keep that property. If the library cannot currently avoid it, I do not expect to be able to avoid it with a new scheme. This is very much more important for PHP that JNI is to Java. Every library shipped with PHP (including most of SPL I believe) is tightly coupled to the interpreter. By contrast, the vast majority of Java's Class library is written in Java. > Also this doesn't necessarily have to replace the Zend API but in fact be an > engine independent API. Over time if everyone adopts then we could get rid of > Zend API. However, if what I say above is correct, we may find that it's > actually very complementary and that some core extensions prefer to hook into > the engine very tightly while third parties (e.g. pdflib) and less core > extensions prefer to stick to an independent API which can work across not > only mini release of PHP but also minor and in some cases major release of > PHP. It doesn't have to, but I think it should. But it would be insane to expect a new scheme to replace the current one, unless it works universally. Core "extensions", like important array and string functions, will probably need to be tightly coupled to the interpreter. Some other extensions would too, like Xdebug. If people could suggest other extensions which should not be decoupled, I would appreciate it. > This API would need to be designed in great detail and we would need to make > sure it is long lasting. I could not agree more. > My 2 cents. > Andi Thanks for the input, the more the merrier :) Paul > >> -----Original Message----- >> From: Paul Biggar [mailto:paul.big...@gmail.com] >> Sent: Monday, March 30, 2009 4:07 PM >> To: PHP Internals >> Subject: [PHP-DEV] RFC: Removing the Zend API >> >> Hi, >> >> I've added a new RFC to the wiki >> (http://wiki.php.net/rfc/remove_zend_api). It details a plan to try >> and decouple the Zend engine from the libraries, in order to allow >> large scale changes to the Zend engine in the future. The RFC >> describes a prototype phase of the project, which could reasonably be >> done within a GSOC project, so I have added it to the GSOC 09 page >> (http://wiki.php.net/gsoc/2009#prototyping_removal_of_the_zend_api). >> >> If anybody has any comments, I'd be delighted to hear them. If anybody >> knows (or is) a good student looking for a GSOC project (and I've left >> it late, there are only 3 days left to apply), please encourage the >> student to look at this. Finally, if anybody is interested in helping >> mentor this as part of the GSOC, I'd be grateful for the help (I have >> to start writing my thesis soon). >> >> Thanks, >> Paul >> >> -- >> Paul Biggar >> paul.big...@gmail.com >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php > > -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
