On 06-09-2013 18:39, Nikita Popov wrote:
I created an RFC and preliminary implementation for named parameters:
https://wiki.php.net/rfc/named_params
The RFC and implementation are not yet complete. I mainly want to have
feedback on the idea in general and on the Open Questions (
https://wiki.php.net/rfc/named_params#open_questions) in particular.
I like the idea, but I think you're approaching this the wrong way. In
my opinion, you should emulate the current behavior as close as
possible. For instance:
func_get_args() will not include the missing offsets in the resulting array
Why not? Why not include the default value in the missing offset? This
is not possible for internal functions, but I've talked in depth about
the problems that skipping parameters introduces and they're not
different here (though I should say those problems are not intractable
and I think the cost/benefit analysis here is completely different).
func_get_arg($n) will throw its usual “Argument %ld not passed to function”
warning and return false
Again, why not return the default value?
This section is also problematic:
All three functions are also oblivious to the collection of unknown
named arguments by variadics. func_get_args() will not return the
collected values and func_num_args() will not include them in the
argument count.
(...)
I think the correct course of action is just to drop support for extra
named arguments. Just add an extra array argument to the function and
you have equivalent functionality without having to go through these
edge cases.
I also disagree about your idea about how to handle changed parameter
names. Having an E_ERROR here is absolutely unacceptable. This would be
a major BC break (not to mention inconsistent with the other other
signature mismatches are handled). In fact, I think ANY message here
would waste millions of $currency in man hours. I can't think of any
easy solution there. An alternative solution would be to keep a flag on
whether argument names changed and refuse to accept named arguments in
the case a call is made to an instance whose class or some its parents
changed parameter names, but this comes with some memory penalty.
In conclusion, if you drop one dubious feature and present to the callee
the same state as before (as if the caller had passed the skipped
parameters with the default arguments), this would ease the
implementation and the transition, especially for userland code.
Regards
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php