> De : p...@golemon.com [mailto:p...@golemon.com] De la part de Sara Golemon
>
> 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 think it's time to define a scope for a first step, eg rules to know if a
given if an extension
Is eligible to the tools we are planning in this first step. Some may consider
it as a waste of time but, when I think we must know where to stop before
starting anything.
If you agree, I propose this as a base to refine:
- Extension exposes only PHP functions and constants (no OO),
- Each PHP function argument must accept a scalar, an array, or both ('mixed'
case).
- PHP functions return value type can be any scalar type or array.
- one or more PHP function arguments can be optional
- PHP function arguments can be passed by value or by reference.
This constraints should fit a lot of 'bridge-only' extensions. I don't include
OO because, IMO, storing properties is going too far for a 1st step.
I am starting a prototype of an C-code extension generator, written in PHP,
using high-level function definitions. For each exposed function, the
high-level definitions mostly define input arguments and return value. The
generator handles all aspects of argument parsing, going much further than the
current parsing API. It also handles return values, keeps the C code away from
zval manipulation.
The implementation will be split between a generic part, which will read and
format input files in memory, and pluggable generators. Each generator will
have the responsibility to generate everything needed by a specific PHP engine.
For instance, the generator for the PHP interpreter will generate everything
needed to run phpize/configure/make.
I will tell you when I have a model and examples of metadata definition and
input files, so that you can tell me if it fits your needs (as I don't know
HHVM yet).
One more thing : Do you know which existing PECL extension we could use for a
proof of concept ? This should comply with our scope (basically, expose
functions and constants only) but a small one would be better. I thought about
newt but it defines more than 200 functions...
I also realize that this stuff should probably go to an RFC now...
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
