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
