On Thu, Jan 8, 2015 at 9:56 AM, Fred Emmott <f...@fredemmott.co.uk> wrote: > >> On Jan 7, 2015, at 2:18 AM, Pierre Joye <pierre....@gmail.com> wrote: >>> That's very much the case. One extension, one "install". It doesn't >>> matter whether some of the extension is written in C, and other parts in >>> PHP. HHVM is *all* about this. Making use of C where you need it, and >>> otherwise just write the simpler *but integral* border functionality in >>> PHP for faster maintenance and development. >> >> It is not correct nor relevant to compare hhvm extension development with >> this case. With hhvm it ends up with an actual native extension while here >> it is proposed to bundled script that will be executed at runtime like any >> other script, except that nothing can be done with them, not even disable >> them if not required (like using its own glue codes). > > > Both HHVM and its' extensions embed PHP source in the binaries. > > In our experience: > + bundling them together makes it much quicker to iterate and improve > extensions.
Releasing them together allows that. Bundling does not help to improve extensions, eventually make it easier to install but that's about it. > + the PHP code tends to use ‘non-public’ parts of the C API - so it really > needs to be kept in sync with the PHP version. I’m not sure if composer > currently supports ‘if I’m on PHP 5.6.0 use this library, if I’m on 5.6.1 use > this library…’. While this is fixable, it seems like a lot of boilerplate. > + If PHP7 does develop a JIT, the PHP implementations could be faster than > calling the C code (type specializing, and the overhead of setting up the > stack for a C function call). This is often the case for HHVM. How does it help? For php, an extension will be built against a given version. Unless a script per version is created, bundling script will be of no help for extensions developers as most of the extensions can be built against many versions. I have no idea if there are custom hhvm extensions out there, but they will have to deal with the same issue. How to make it work with multiple version of hhvm.This is not the case now for the bundled ones, they are kept in sync with hhvm directly, just like the core php extensions are in sync with the engine changes. Off topic: btw, how we want to deal with 5.x and 7.x from an extension point of view is still a big question. Multiple branches, multiple src files, multiple releases, etc. > - we currently do not support extension-style parameter coercion in PHP > functions; this leads to small incompatibilities in our case, which we > usually address by writing a C++ function that proxies to a hidden PHP > implementation. For PHP7, if the current scalar types RFC lands, this won’t > be a problem; if it doesn’t, there’s a chance that multiple functions from > the same extension will have confusingly different parameter coercing > behavior, depending on the author’s rigor. I hope it will pass, we cruelly need that :) > We solved some of the other problems by only allowing definitions, no > side-effects - classes, constants, namespaces etc. We do not allow code > outside of a function body here. Yes, we will have to do that, no matter what we choose. I am however not sure how to do it with the current engine design. Using zend_compile (or a derived implementation) may help. > HHVM-specific details (just FYI, agree that they’re probably not particularly > relevant): > > * We do not translate the PHP source to native code (unless it ends up being > jitted at runtime) Which is very likely to be the case for codes used in many requests. PHP does not have JIT, certainly not in 6.0, maybe in 6.x tho' > * We’re planning on supporting the extension-style coercion in Hack code with > a user attribute All in all, I have a hard time to compare hhvm to php in this case. It is not really PHP. hhvm is by design much more suited to allow that, additional syntax and JIT make this whole thing a totally different story. The fact that hhvm implements a significant part of the extensions (or other areas) using PHP+additional syntax as well as adding cleaner APIs or mechanisms for the C parts only confirms me one thing: the very 1st problem we have to solve is to ease the extension creation, by drastically changing the internals APIs & tools. Bundling script does not help here, we are using a scotch tape to repair something that should have been replaced or redesigned since long already. I am not blaming anyone, the engine design, historically, does not make such changes easy. Cheers, Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
