> De : p...@golemon.com [mailto:p...@golemon.com] De la part de Sara Golemon > > Okay, but why even generate code for argument parsing? Why not just > pass the arguments/return-values as their concrete type?
Because I am beyond what macros can do. Actually, I don't see how I can do what I have in mind with macros. And, IMHO, it is much more user-friendly. What I am trying to implement is a tool which requires as few knowledge about PHP internals as possible. I want an average C programmer to be able to connect a C library and build the whole extension in a few hours, even if he never did it before. And the generated extension should work on every PHP flavor supported by the tool. That's why I am favoring a synthetic definition of the API using a markup language. If you have a few minutes, I'd like you to read the doc I have written : https://github.com/flaupretre/php-ext-gen/blob/master/doc/schema.yml is the metadata schema. https://github.com/flaupretre/php-ext-gen/blob/master/doc/variables.md is an overview of PHP/C variable mapping. You may also have a look at the 'examples' subdir. Two extensions are defined there. They don't expose much but they are ready for code generation. The most complex case I have found is a mixed array/string argument, passed by ref, receiving an array, and function wants to return a string. Doing this without the developer even knowing that zvals exist is quite challenging. I may be wrong but I think it cannot be done with C macros or with an intermediate bidirectional conversion layer. > Could you explain what you mean by this? I'm not sure where nested > arrays come from. I think we are not talking about the same mechanisms. What I am talking about is the way to describe an extension, so that a tool can take this description and generate the extension for different flavors of PHP engine. As this description is a tree and you said it can be done in PHP, I imagined that you wanted the user to write the metadata tree in PHP. But you probaly have something completely different in mind. It seems that, starting with the same needs, we are designing completely different solutions. > For example, the PHP code could be something as simple as the > following (but see below, I don't think this is necessarily a good > idea): > > function NATIVE_STRING_foo(int $bar, float $baz = 3.14) {} > > Although scalar type hints aren't supported, we can actually fake them > in the parser letting them look like class type hints, then converting > them post-parse. Meanwhile, a function with an empty body named > "NATIVE_T_*()" indicates its a stub, and what type it returns. Ugly, > yes. But compatible with all PHP parsers 5 and later. > > Then in the C/C++ side, we present: > > php_string foo(int bar, double baz) { > /* Normal(ish) C code goes here */ > } Mmh, why not... I agree that, for int and double, it is perfect. For bool too :) But how do you handle passing args by ref, mix-typed args (especially when passed by ref), nullok, multi-typed return value (the classical 'string or false' for instance), optional args (can be passed by ref too) ? And passing arrays in and out ? I don't understand how such a model can fit our needs. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
