Re: Revisiting the "Named Arguments" RFC

First of all, I'd love seeing this feature in PHP, and it would be a very large incentive to upgrade to 5.6 asap when it would be included (without bugs of course :) I'd like to offer my thoughts on the open questions in the RFC: Regarding Syntax at the call site, I feel that it is exactly right the way it is proposed / implemented now. That way mirrors most closely the syntax of static array definition, while saving some typing (omitting of double quotes) where key names do not clash with keywords. In fact, once established, I would love static array initialization to also permit nonclashing keys to omit the doublequotes :) One question, given that syntax: would $foo = 'bar'; test($foo => 123); pass a named parameter named 'bar' ? That would be my visual expectation, and is what feels wrong about the alternate proposals. Regarding the separation of positional and named stuff when packing/unpacking (the python *kw vs. **kw distinction) I feel that would be unnatural. There is no syntactic precedent in PHP regarding notation, and I think where desired, explicit code using array functions should always easily be able to make the split in an obvious fashion. Regarding signature violation, and clearly just as a personal opinion, I don't see LSP as a law of languages, but just as a good coding practise. Thus, I would be happy to just have the same runtime checks in place for ordinary functions, against the actual method called, with exactly the same error behaviour as for ordinary function calls, instead of an additional set of errors and/or warning coming from structural checking of child and parent methods. I think that's what the RFC / current implementation does, but the RFC seems unclear in that regard. Finally, regarding internal functions and their arginfo and the naming of parameters there... in my imagination, that is the think that would still need the most work, and would tend to bikeshedding regading the parameter names set in stone in the process... Which leads me to the question whether that work wouldn't be best postponed: - create variations of the arginfo declarations that explicitly say, on a function-by-function basis, whether named parameters should be supported - forbid use of named parameters with any function not yet modified and reviewed in that fashion Personally, being able to use named parameters in our own userland functions and classes, is much more important than use against internal functions, and postponing the feature altogether due to the internal functions not being fit to accept named parameters, would be sad. best regards Patrick