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 <dmi...@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ł Brzuchalski <mic...@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 (a...@php.net); PHP internals list
> *Subject:* Re: [PHP-DEV] PHP FFI extenesion
>
>
>
> 2018-04-17 9:46 GMT+02:00 Dmitry Stogov <dmi...@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 = $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 =
> FFI::new($libc->timezone);
>
> At least, this should eliminate C parsing overhead.
>
>
> Thanks. Dmitry.
> ------------------------------
> *From:* Michał Brzuchalski <mic...@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 (a...@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 = new Libc\Timezone();
> $tv = 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 <dmi...@zend.com>:
>
>
>
> On Apr 17, 2018 2:49 AM, Stanislav Malyshev <smalys...@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 and
> 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 web
> 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
> smalys...@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 and
> 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
> smalys...@gmail.com
>
>
>
>
> --
> regards / pozdrawiam,
> --
> Michał Brzuchalski
> about.me/brzuchal
> brzuchalski.com
>
>
>
>
> --
> regards / pozdrawiam,
> --
> Michał Brzuchalski
> about.me/brzuchal
> brzuchalski.com
>
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
