Hi! > Funny to see you mention this. I literally just pulled together a > meeting today to discuss HHVM's admittedly unstable extension API. > One idea to emerge from this was to design a new extension API > agnostic of underlying implementation. An API which, if done right,
What extensions do right now is pretty closely linked to how the engine is functioning. Of course, for simple things like "take number from C library, wrap it in zval, send to PHP" the API would be pretty simple, but if you have something like simplexml, it relies a lot on the details of the engine and how things are done there. So I think it would be useful to define what exactly would be covered and what not, i.e. which APIs are supported, which can be supported, which can not. Right now we don't even have the API as such for the engine itself (i.e., you can just go to EG(...) or bits of the zval and mess with them, and not only you can but many extensions do). Also I wonder how that would sit with phpng effort. Lately it was very focused on performance-based optimizations, and working via abstract APIs may not be always the most performant way of doing things. > learn from. Heck, we're actually halfway there with HHVM's > "ext_zend_compat" layer, which makes PHP extensions (mostly) source > compatible with HHVM. Is there some docs for what ext_zend_compat does and which APIs it supports/doesn't support? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
