On Sat, Jan 10, 2015 at 8:08 PM, Sara Golemon <poll...@php.net> wrote: > On Sat, Jan 10, 2015 at 2:39 PM, Stanislav Malyshev <smalys...@gmail.com> > wrote: >> 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). >> > My idea is to cover *most* (but not all) extensions with a narrower, > simplified API. As you say, many interactions fall into the "marshal > this engine value to a C type as needed". This can cater to the > bread-and-butter of PHP extensions very well. >
More than adding a new layer, I would love to see something similar to hhvm or Zephir available by default. If C is used, then only the relevant parts have to be implement by the developers, skipping all the over complicated data mangling, swapping, exchange, etc between userland and the engine. It is then relatively easy to end up generating codes for either php, hhvm or any other platform. Using builtin script (yes, in this case it could be a nice thing), it could became a very nice way to develop php&co extensions. For what I can imagine (I did not remotely try to implement it yet) is to find a way to parse, say, a php script which include custom sections for C (or C++) codes. We could use comments but I do not like the idea, mainly because it will be tricky to have editors support :) One problem, I do not think it is possible to customize the current lexer to allow that on demand, but it could be possible using a more modern lexer tools. I am not sure how flexible the hhvm lexer is or if we should have yet another language (as I would rather use plain PHP in this case, even if it makes the task slightly harder to implement or generate slightly bigger native code due to type checking or conversions). Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
