Levi Morrison wrote:
> One thing I really want to work towards in the future is consistency
> between user-land and internal functions. There are currently multiple
> observable differences.
+1, as they say.
This is the goal we should be aiming for. Having differences between
userland and internal functions seems to be a more important problem
that should be solved compared to a lack of detail in reflection.
Stanislav Malyshev wrote:
> Well, if we move to checking in ZPP only, then some of the errors that
> previously were fatals (like iterator_array("")) would now become
> warnings. In fact, even type mismatch is a warning for ZPP, which may
> be unexpected, as it was a fatal before, so we may want to change that.
> ...
> So we may want to be careful there.
I'm pretty sure we do need to be careful and think through the change.
Doing an RFC for this is usually the best way of doing that, rather
than just committing changes to master until something sticks.
If there was to be an RFC, some things to be discussed would be:
1. Currently the arg info is separated from the actual parsing of the
parameters. While in a few cases this may be necessary, for the vast
majority of code it is not needed. Having the information be
duplicated is one of the main causes of the arg info not accurately
reflecting the parameters the function actually needs.
Wouldn't the best way to solve this (both now and to prevent future
'drift' of the arg info from the actual required args) be to allow the
arguments to be defined in one place, and then used by both the arg
declarations and the function ZPP, through the clever use of macros?
2. How are we going to handle functions that use the ability of
internals to have wildly different acceptable sets of parameters. For
example
https://github.com/php/php-src/blob/master/ext/intl/calendar/gregoriancalendar_methods.cpp#L82
can accept either "|Z!s!" or "lll|lll" for the parameters.
This is one of those places where an internal function can behave
differently from a userland function, and so the reflection in PHP
currently isn't powerful enough to give information about these cases.
3. Parameter names - although I am personally not in favour of any of
the named parameters RFCs, other people are. One of the big chunks of
work that would be needed for this is to correct the names of the
parameters in arg info to be the same as they are in the manual (or
vice versa), as well as keep them 100% in sync. If people are serious
about wanting named parameters they probably ought to be in the
discussion to clean up the arg info, as otherwise the info would need
to be cleaned up twice, which could be a large duplication of work and
BC break.
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
