Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103632
To: Dmitry Stogov <dmitry@zend.com>, Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
References: <DM6PR02MB5932B1C5B8A707FB8DF76679BFBF0@DM6PR02MB5932.namprd02.prod.outlook.com>
 <CAF+90c_VYryOPO24_L4R7+HMBr9NqC7wHZ_qGohsqom6j8Da9g@mail.gmail.com>
 <fc17092c-dc1a-96fc-d8e3-660291008cec@zend.com>
Message-ID: <8811ec53-2473-ddb3-5642-bb8dc88edb72@gmx.de>
Date: Mon, 24 Dec 2018 14:50:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <fc17092c-dc1a-96fc-d8e3-660291008cec@zend.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] [VOTE] FFI - Foreign Function Interface
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 24.12.2018 at 08:38, Dmitry Stogov wrote:

> On 12/22/18 1:32 PM, Nikita Popov wrote:
>
>> My main concern here is that this is a very new extension and I think 
>> that apart from you barely anyone had a chance to actually implement 
>> something based on it and gain experience using the proposed API. 
>> Bundling an extension with PHP means that the API becomes frozen in time 
>> and it becomes very hard to change anything.
>> I think that having FFI support is important, but I'm afraid that once 
>> we bundle this extension and it will see more usage, it will quickly 
>> turn out that the API needs to change to make it easier to use or 
>> accommodate more use-cases.
> 
> The API almost completely repeats LuaJIT and Python CFFI (that are 
> stable). Something might need to be improved, of course, but only in 
> case the extension is going to be widely used.

If we are concerned about the API stability, we could mark the extension
as experimental and exempt it from our usual BC guarantee, as suggested
by Niklas[1].  On the other hand, if PHP 8 will be next after PHP 7.4,
this may not even be necessary.

> The main reason, I like to have this in core - future integration with JIT.

It seems to me that JIT integration of FFI isn't the whole story, but
rather an intermediate step to be able to offer built-in functionality
written in PHP in the long run, which could be a huge enhancement.  Am I
correct?

Anyhow, my main concerns regarding the proposal are that people could
easily be led into thinking that FFI is *the* new way to interface with
external code, rendering classic extensions obsolete, and that
interfacing on the ABI level is even more error-prone than interfacing
on the C API level.  Both concerns could be alleviated by good
documentation, though.

[1] <https://externals.io/message/103613#103623>

-- 
Christoph M. Becker