On Tue, Jul 23, 2019 at 5:00 PM Nikita Popov <nikita....@gmail.com> wrote:
> On Tue, Jun 18, 2019 at 5:10 PM Nikita Popov <nikita....@gmail.com> wrote:
>
> > Hi internals,
> >
> > In PHP 8 it will be possible to add reflectible argument and return type
> > information for internal functions (it was previously theoretically
> > possible as well, but forbidden by policy for php-src for multiple
> reasons,
> > which have now been resolved).
> >
> > It will take quite a bit of effort to add this information for hundreds
> of
> > builtin functions. I would like to take this chance to improve the way in
> > which arginfo structures are specified, and make it more ergonomic and
> > future proof. Here is an example of a typed arginfo structure:
> >
> > ZEND_BEGIN_ARG_WITH_RETURN_TYPE_INFO_EX(arginfo_class_alias, 0, 2,
> > _IS_BOOL, 0)
> > ZEND_ARG_TYPE_INFO(0, user_class_name, IS_STRING, 0)
> > ZEND_ARG_TYPE_INFO(0, alias_name, IS_STRING, 0)
> > ZEND_ARG_TYPE_INFO(0, autoload, _IS_BOOL, 0)
> > ZEND_END_ARG_INFO()
> >
> > Rather than writing this out by hand, I would like arginfo structures to
> > be generated from PHP stub files that contain definitions like this:
> >
> > function class_alias(string $user_class_name, string $alias_name, bool
> > $autoload = true): bool {}
> >
> > I've created a proof of concept implementation for this at
> > https://github.com/php/php-src/pull/4284. Function signatures are
> > specified in a xyz.stub.php file from which xyz_arginfo.h is generated.
> > This file can then be included in the implementation. Nothing about the
> > arginfo implementation itself changes.
> >
> > What do you think about providing this mechanism?
> >
> > Nikita
> >
>
> Any more feedback on this?
>
> The existing discussion has been mostly around "can we get the type
> information from some existing source?" to which the answer is "nope":
> Nothing that already exists is accurate enough for php-src.
>
> Nikita
>
Would it be too aggressive to have (in the php-src test suite, as a first
step) something that ensures that a stub exists for each exposed userland
symbol?
That would ensure that any newly added symbol or core extension has the
matching userland reflectable-ish structure, which later (hopefully, in the
years) could lead to having proper reflection on internal symbols...
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
