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