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

Reply via email to