Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110888
MIME-Version: 1.0
References: <1594071415.546211499@f420.i.mail.ru>
In-Reply-To: <1594071415.546211499@f420.i.mail.ru>
Date: Thu, 9 Jul 2020 09:01:19 +0100
Message-ID: <CA+kxMuRvXr7k+uVmYqoQArefFwf3J_TUc0ise=uxn0S-cv7GpQ@mail.gmail.com>
To: =?UTF-8?B?0JrQuNGA0LjQu9C7INCd0LXRgdC80LXRj9C90L7Qsg==?= <nesk@xakep.ru>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] FFI Improvements: Consistency and soliving some problems
From: Danack@basereality.com (Dan Ackroyd)

On Mon, 6 Jul 2020 at 22:37, =D0=9A=D0=B8=D1=80=D0=B8=D0=BB=D0=BB =D0=9D=D0=
=B5=D1=81=D0=BC=D0=B5=D1=8F=D0=BD=D0=BE=D0=B2 <nesk@xakep.ru> wrote:
>
> I would like to start discussion about the =C2=ABFFI Improvements=C2=BB R=
FC. At the moment, I do not have the right to create wiki page, so I post i=
t on the github:  https://github.com/SerafimArts/php-rfcs/blob/ffi-improvem=
ents/rfcs/0000-ffi-improvements.md
>

Thanks for starting this discussion. I think FFI definitely needs to
be improved before it will see widespread adoption.

> Please note that for backward compatibility, allow option with
> passing a string as the second argument to the FFI::cdef() method.

Rather than changing the function signature of FFI::cdef, I think it
would be better to introduce a new function, and then at some point
deprecate and remove the old one (if anyone cares to).

So rather than FFI::cdef() it could be FFI::ghij() or maybe even a
name that is somewhat meaningful.

For FFI_LIB, FFI_SCOPE, and FFI_LIB_DIR your proposal sounds sensible.
It would be really good if someone involved in getting FFI into core
could comment if there was any specific reason for not doing that
already.

One other thing that probably also should be addressed is the
behaviour around closures that was noted in the RFC
https://wiki.php.net/rfc/ffi#php_callbacks:

> It's possible to assign PHP closure to native variable of
> function pointer type (or pass it as a function argument).
> This works, but this functionality is not supported on all libffi
> platforms, it is not efficient and leaks resources by the end of
> request. It's recommended to minimize the usage of PHP callbacks.

I really don't know what can or should be done for that, but having a
feature that can't be used safely seems like a bad feature.

cheers
Dan
Ack