Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:80436 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 80775 invoked from network); 13 Jan 2015 06:09:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Jan 2015 06:09:08 -0000 Authentication-Results: pb1.pair.com header.from=francois@tekwire.net; sender-id=softfail Authentication-Results: pb1.pair.com smtp.mail=francois@tekwire.net; spf=softfail; sender-id=softfail Received-SPF: softfail (pb1.pair.com: domain tekwire.net does not designate 212.27.42.2 as permitted sender) X-PHP-List-Original-Sender: francois@tekwire.net X-Host-Fingerprint: 212.27.42.2 smtp2-g21.free.fr Received: from [212.27.42.2] ([212.27.42.2:4801] helo=smtp2-g21.free.fr) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 26/64-51796-286B4B45 for ; Tue, 13 Jan 2015 01:09:07 -0500 Received: from moorea (unknown [82.240.16.115]) by smtp2-g21.free.fr (Postfix) with ESMTP id CFBF54B017C; Tue, 13 Jan 2015 07:06:52 +0100 (CET) Reply-To: To: "'Sara Golemon'" Cc: "'Pierre Joye'" , "'Stanislav Malyshev'" , "'PHP internals'" References: <54B1AA31.6050703@gmail.com> <003901d02de5$53732480$fa596d80$@tekwire.net> <005a01d02e1a$02d27a00$08776e00$@tekwire.net> <008f01d02e67$6e92ad80$4bb80880$@tekwire.net> In-Reply-To: Date: Tue, 13 Jan 2015 07:08:57 +0100 Message-ID: <00d701d02ef7$6afd7660$40f86320$@tekwire.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHdpO6kBDBjSAQ05ND+I0bfKmNeFQIeJCUTAflXB0ABzhWVuwG23BUcAlMscacBvL1qjQIsV4OvA0CmhBICMZMuqZwIO5Tw Content-Language: fr X-Antivirus: avast! (VPS 150112-1, 12/01/2015), Outbound message X-Antivirus-Status: Clean Subject: RE: [PHP-DEV] One API to rule them all? (Was: Extension Prepend Files) From: francois@tekwire.net (=?UTF-8?Q?Fran=C3=A7ois_Laupretre?=) > De : php@golemon.com [mailto:php@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): >=20 > function NATIVE_STRING_foo(int $bar, float $baz =3D 3.14) {} >=20 > 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. >=20 > Then in the C/C++ side, we present: >=20 > 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=C3=A7ois