On 06-09-2013 23:54, Nikita Popov wrote:
On Fri, Sep 6, 2013 at 11:23 PM, Gustavo Lopes <glo...@nebm.ist.utl.pt>wrote: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.Dunno, personally I don't have a strong need for the extra named args. That's something Stas considered important (in the discussing re skipparams RFC). Would be interesting to know for what they are currently used in Python/etc and whether those use cases are sufficiently important to us.
The advantages would have to be very significant in order to justify breaking all the call forwarding code out there relying on call_user_func() and func_get_args().
It also unnecessary complicates the variadics calls for the callee that now receives a potentially non-numeric array. The caller may have slightly better syntax, but there being no information on support of extra named parameters on the signature is an extra complication. And at this point I haven't seen any convincing argument as to how this is more than marginally better than an extra array argument for the caller and any better at all for the callee.
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).Yes, I certainly do not want to throw any fatal-ish error here. Maybe I didn't make that clear in the RFC. (What do you mean with "inconsistent with the other other signature mismatches are handled" though? For signature mismatches involving interfaces we currently use fatal error. Signature mismatches between classes are E_STRICT.)
I meant the E_STRICT on rather more worrying situations like:
class A { function a(array $a) {} }
class B extends A { function a(SplArray $a) {} }
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.Eh, I don't know. Getting an error at the call-site is already too late. You'll get one anyway because the parameter name doesn't exist. Unless mismatching parameter names are exceedingly common, I'd think a lowly E_STRICT level error would be bearable.
Too late for what? If there is a mismatch but named arguments are not used, there is no problem with the code (if you don't consider named parameters not being permitted a problem). In any case, a more specific error is better than a generic one.
That said, I'm on the fence here because it's not really nice to have named parameters being permitted in a call to method A::b() but having the same call forbidden to B::b(), where B extends A.
Regards -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
