Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102051
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain brzuchalski.com from 188.165.245.118 cause and error)
MIME-Version: 1.0
In-Reply-To: <BN6PR02MB3234A38F7ED99529068D0A56BFB70@BN6PR02MB3234.namprd02.prod.outlook.com>
References: <BN6PR02MB323404E036380FA42924D9A7BFB30@BN6PR02MB3234.namprd02.prod.outlook.com>
 <56794c33-a728-d399-2462-b62ba1b7a509@gmail.com> <af4cb226-df79-4b29-810e-52028792c37d@email.android.com>
 <CABdc3WpJhd9csdqtUW4KgRqmiq5vmnbrxEXjskAgPPf96nZk+w@mail.gmail.com>
 <BN6PR02MB323410849DDE3D30E225D2D0BFB70@BN6PR02MB3234.namprd02.prod.outlook.com>
 <CABdc3WphObv_YAfpMgKJ9MA-CBSs6F2tN=N5wJEQ-AxEZ3J64A@mail.gmail.com> <BN6PR02MB3234A38F7ED99529068D0A56BFB70@BN6PR02MB3234.namprd02.prod.outlook.com>
Date: Tue, 17 Apr 2018 12:04:46 +0200
Message-ID: <CABdc3Wowgb+iM3PUXp__cNutekNqOd707a=4JBzuVY2uo5sUTg@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, Zeev Suraski <zeev@zend.com>, Xinchen Hui <laruence@gmail.com>, 
	Nikita Popov <nikic@php.net>, Bob Weinand <bwoebi@php.net>, 
	"Anatol Belski (ab@php.net)" <ab@php.net>, PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000da79be056a08774d"
Subject: Re: [PHP-DEV] PHP FFI extenesion
From: michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--000000000000da79be056a08774d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

One more idea I can imagine - while creating FFI object would it be
possible to:
* declare all ZEND_FFI_SYM_FUNC as class methods with proper type hinting
mapped to registered classes
* declare all ZEND_FFI_SYM_VAR as class properties with some guards
* declare all ZEND_FFI_SYM_CONST as class public consts

It would be possible to use reflection then.
But that I suppose should require extending FFI and registering symbols
into newly created class_entry.
It is possible that I'm overcoming and inventing right now. If so, just
ignore me :)

2018-04-17 10:55 GMT+02:00 Dmitry Stogov <dmitry@zend.com>:

> Now, I got your idea.
>
> Subclassing CData, and use that types for type hinting may make sense.
>
> I'll put this idea in my TODO, but with low priority.
>
>
> Thanks. Dmitry.
> ------------------------------
> *From:* Micha=C5=82 Brzuchalski <michal@brzuchalski.com>
> *Sent:* Tuesday, April 17, 2018 10:51:32 AM
>
> *To:* Dmitry Stogov
> *Cc:* Stanislav Malyshev; Zeev Suraski; Xinchen Hui; Nikita Popov; Bob
> Weinand; Anatol Belski (ab@php.net); PHP internals list
> *Subject:* Re: [PHP-DEV] PHP FFI extenesion
>
>
>
> 2018-04-17 9:46 GMT+02:00 Dmitry Stogov <dmitry@zend.com>:
>
> Hi Michal,
>
>
> I didn't think in this way. I liked to make the simplest API.
>
> I don't expect wide FFI usage in frameworks :)
>
>
> BTW: I like the idea of use C type names (probably, we may reuse original
> C type names without additional registration).
>
>
> currently we can do: $tz =3D $libc->new("struct timezone");
>
>
> My point was ability to provide an identity to objects wich acts as a
> structs. CData class has no idea of what struct type it is and I cannot
> type hint over that, thats why I thought it would be usefull.
> I could then prepare a vendor using pure PHP and wrap everything using
> types.
>
>
>
> I'll think, if we can existend API to use something like: $tz =3D
> FFI::new($libc->timezone);
>
> At least, this should eliminate C parsing overhead.
>
>
> Thanks. Dmitry.
> ------------------------------
> *From:* Micha=C5=82 Brzuchalski <michal@brzuchalski.com>
> *Sent:* Tuesday, April 17, 2018 10:24:02 AM
> *To:* Dmitry Stogov
> *Cc:* Stanislav Malyshev; Zeev Suraski; Xinchen Hui; Nikita Popov; Bob
> Weinand; Anatol Belski (ab@php.net); PHP internals list
> *Subject:* Re: [PHP-DEV] PHP FFI extenesion
>
> Hi Dmitry!
>
> I am not much experienced with C but as a user, I'm just wondering if
> there is a possibility to extend FFI class and autoregister all or just
> chosen structs as classes, for eg.
> class Libc extends FFI {
>     public function __construct() {
>         parent::__construct("...code", "...lib"); // tmp notation
>         $this->register('struct timeval', Libc\Timeval::class); // I
> assume they would extend CData
>         $this->register('struct timezone', Libc\Timezone::class); // as
> above
>     }
> }
>
> So I can instantiate
>
> $tz =3D new Libc\Timezone();
> $tv =3D new Libc\Timeval();
>
> and then pass them FFI function
>
> (new Libc())->gettimeofday($tv, $tz);
> var_dump($tv-tv_sec, $tv->tv_usec, $tz);
>
> I would be able to prepare than a vendor package with a specified
> autoloader.
> Would that make sense?
>
> Also wouldn't it better if CData class share the same prefixes like
> FFICdata or FFI\CData?
>
>
> Cheers,
> Michal
>
> 2018-04-17 9:18 GMT+02:00 Dmitry Stogov <dmitry@zend.com>:
>
>
>
> On Apr 17, 2018 2:49 AM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> Hi!
>
> > I've spent some time thinking about simple FFI for PHP, and finally,
> borrowed most ideas from LuaJIT.
> >
> > This is an initial PoC. It was tested on Linux only.
> >
> >
> > https://github.com/dstogov/php-ffi
> >
> >
> > I would appreciate review, comments and ideas about missing features an=
d
> functionality.
> >
>
> Looks interesting. On a cursory look, couple of thoughts:
> - I think all the classes involved should be made non-serializable and
> non-unserializable.
>
> Agree.
>
> - Does it load shared libraries, or only uses ones already loaded? If
> the former, I think there should be a way to unload them at the request
> end (even though it might be performance issue, and may be not possible
> if persistent resources are involved), otherwise we leak state between
> requests.
>
> I have a bit opposit idea. We will keep FFI for CLI but disable it for we=
b
> apps (like dl()).
> At the same time, we will develop a technology to preload and reuse  PHP
> files across requests.
> And allow FFI there.
>
> - OTOH, people may want to load a set of persistent definitions from a
> config file, etc. - the ffi definition probably won't change much, and
> having locked down set of FFI interfaces the rest of the code is using
> might be beneficial
>
> Yeah. Like this.
>
> - Since this thing is dealing with raw pointers, etc., from PHP code,
> there may be a lot of crashes from using this extension in a wrong way.
> I wonder which facilities we could provide for helping people to debug
> it (for people who aren't super-comfortable using gdb on PHP engine).
>
> Programming using FFI, is very similar to C.
> I'm not sure, if we may provide good debugging facilities.
>
> Thanks for review.
>
> Dmitry.
>
>
> --
> Stas Malyshev
> smalyshev@gmail.com
>
> Hi!
>
> > I've spent some time thinking about simple FFI for PHP, and finally,
> borrowed most ideas from LuaJIT.
> >
> > This is an initial PoC. It was tested on Linux only.
> >
> >
> > https://github.com/dstogov/php-ffi
> >
> >
> > I would appreciate review, comments and ideas about missing features an=
d
> functionality.
> >
>
> Looks interesting. On a cursory look, couple of thoughts:
> - I think all the classes involved should be made non-serializable and
> non-unserializable.
> - Does it load shared libraries, or only uses ones already loaded? If
> the former, I think there should be a way to unload them at the request
> end (even though it might be performance issue, and may be not possible
> if persistent resources are involved), otherwise we leak state between
> requests.
> - OTOH, people may want to load a set of persistent definitions from a
> config file, etc. - the ffi definition probably won't change much, and
> having locked down set of FFI interfaces the rest of the code is using
> might be beneficial
> - Since this thing is dealing with raw pointers, etc., from PHP code,
> there may be a lot of crashes from using this extension in a wrong way.
> I wonder which facilities we could provide for helping people to debug
> it (for people who aren't super-comfortable using gdb on PHP engine).
>
> --
> Stas Malyshev
> smalyshev@gmail.com
>
>
>
>
> --
> regards / pozdrawiam,
> --
> Micha=C5=82 Brzuchalski
> about.me/brzuchal
> brzuchalski.com
>
>
>
>
> --
> regards / pozdrawiam,
> --
> Micha=C5=82 Brzuchalski
> about.me/brzuchal
> brzuchalski.com
>



--=20
regards / pozdrawiam,
--
Micha=C5=82 Brzuchalski
about.me/brzuchal
brzuchalski.com

--000000000000da79be056a08774d--