Re: Revisiting the "Named Arguments" RFC

Am So. Jan. 12 2014 09:16:13 schrieb Patrick Schaaf: > 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 :) > Not just you! :) > 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. I wondered that too, and I think that is what the engine will do by its own; resolving the variable into its value. Hence, this option won’t be possible; but that’s ok iMO as it’s pretty logical. > 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. +1 - agreed. We already have warnings and exceptions for things such as BadFunctionCall etc. Why not just utilize these instead? That would just save some work! :) > 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. Yeah, I agree. As plain C does not have „real arrays“ such as C++ may offer, it would be ultra hard to code it in. I mean, it is already quite uneasy to use scripted arrays within native functions…or Objects. Hence, I wouldn’t really offer named arguments in that case, as one’d have to create a whole new argument parser and extractor, which would mean even more changes on the actual engine to offer the userland abilities to the „devland“. I agree to not change the C side too much from that point of view. Another thought i had was concerning the => operator. It currently is,as far as I know, used in two things: foreach and arrays. But another suggestion on the page was mentioning a colon: test(word1:“Hello“, word2:“Bar“); Colons are currently only used, afaik, in „shorthand“ if-else statements: $var = (isset($argv[2]) ? $argv[2] : null); And, in another token, its used for static calling: Fubar::meep(); So therefore, I would actually suggest using colons. It does quite mimic the ObjC calling style, but it keeps the old-fashioned function style, which I honestly prefer (besides, adopting an ObjC messaging style syntax would be either ultra-hard or never accepted :D). Kind regards, Ingwie