On Fri, Sep 6, 2013 at 11:23 PM, Gustavo Lopes <glo...@nebm.ist.utl.pt>wrote:
> 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? > These suggestions sound very reasonable. It would require some way to get the default value though. So unless we want to start storing them in the arginfo (meh), I'd have to extract them from the ZEND_RECV_INIT opcodes. Which probably is okay, as we're already doing it in Reflection. > 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. > 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. > 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.) > 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. Nikita
