On Sun, Jan 11, 2015 at 8:40 AM, Sara Golemon <poll...@php.net> wrote:
> On Sat, Jan 10, 2015 at 11:18 PM, Pierre Joye <pierre....@gmail.com> wrote:
>> 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.
>>
> And this is one of the things I love about HHVM's current extension
> API, so yeah I'd like to bring some elements of that in if possible.
> At one extreme it means changes to the lexer/parser, and the other end
> it might mean a combination of prepend files (which are pure PHP) and
> either an interface-definition file (simplified version of PHP) or
> something like PHP's current API "inject a function/method here, and
> here's the signature". I imagine this being one of the longer
> portions of our discussions since a lot of folks are going to have
> opinions on what approach is better.
I have a working proof of concept using something like:
<?php
function u_foo() {
}
?>
---- native
void foo()
{
printf("Hello from native!");
}
?>
<?php
... some other codes.
?>
Need a refactoring and some sanity checks but the concept works. It
indeed relies on my patch to bundle the concatenated PHP scripts
sections as the builtin script, generating .c files from the other
parts as well as the config.* and other files.
Ideally I like to include that in pickle, so one can package a release
from the PHP files/repo to generate the resulting extension package.
I will continue later this week and push it to github as soon as I
have a very draft working version for someone else than me :)
>> 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 :)
>>
> That's ambitious, but not impossible. :)
I worked around that for now, could even work with 5.x if we expose
(internally) zend_execute_string :)
>> 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).
>>
> PHP as the greatest-common-denominator makes sense to me too. Much as
> I like the flexibility of user attributes in HHVM, the goal of this
> API layer is to be engine agnostic, so syntax should fall into
> php-langspec, deviating as little as possible.
Full ack.
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
