Hello there.
Within one of the recent votes, I was reminded upon an RFC for named parameters/arguments - to be exact, this one: https://wiki.php.net/rfc/named_params
I just wanted to know if this RFC is still in discussion, has been dropped, or what else is currently being up with it. Because in my opinion, that’d be a very useful addition - as many modern languages support this kind of feature already. The only language that I personaly am using that supports that is Objective-C - and in there, it is very useful. Although its quite different - it’s a different call-style entirely - I could imagine the implementation from the link above to be very useful in PHP.
It would be great to know the current state of the RFC, as I didn’t really see anything of its current state on the page itself.
Kind regards,
Ingwie
I've heard that it's waiting for the EngineException RFC to go
through, as the implementation with it is much stronger than without
it.
On Sat, Jan 11, 2014 at 10:42 AM, Kevin Ingwersen
ingwie2000@googlemail.com wrote:
Hello there.
Within one of the recent votes, I was reminded upon an RFC for named parameters/arguments - to be exact, this one: https://wiki.php.net/rfc/named_params
I just wanted to know if this RFC is still in discussion, has been dropped, or what else is currently being up with it. Because in my opinion, that’d be a very useful addition - as many modern languages support this kind of feature already. The only language that I personaly am using that supports that is Objective-C - and in there, it is very useful. Although its quite different - it’s a different call-style entirely - I could imagine the implementation from the link above to be very useful in PHP.
It would be great to know the current state of the RFC, as I didn’t really see anything of its current state on the page itself.
Kind regards,
Ingwie
Just as a guy in the outside looking in, it would be great to have this. I really hope to see it in 5.6.
Thank You For Your Time,
Mark 'Dygear' Tomlin
I've heard that it's waiting for the EngineException RFC to go
through, as the implementation with it is much stronger than without
it.On Sat, Jan 11, 2014 at 10:42 AM, Kevin Ingwersen
ingwie2000@googlemail.com wrote:Hello there.
Within one of the recent votes, I was reminded upon an RFC for named parameters/arguments - to be exact, this one: https://wiki.php.net/rfc/named_params
I just wanted to know if this RFC is still in discussion, has been dropped, or what else is currently being up with it. Because in my opinion, that’d be a very useful addition - as many modern languages support this kind of feature already. The only language that I personaly am using that supports that is Objective-C - and in there, it is very useful. Although its quite different - it’s a different call-style entirely - I could imagine the implementation from the link above to be very useful in PHP.
It would be great to know the current state of the RFC, as I didn’t really see anything of its current state on the page itself.
Kind regards,
Ingwie
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
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
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).
It also looks like C#'s named arguments.
--
Andrea Faulds
http://ajf.me/
Am So. Jan. 12 2014 18:02:39 schrieb Andrea Faulds:
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).
It also looks like C#'s named arguments.
Oh really? Good to know, I never did anything more than Hello World with C#, because I dont trust in Mono a lot on OS X ^^;
Am 12.01.2014 18:07, schrieb Kevin Ingwersen:
Am So. Jan. 12 2014 18:02:39 schrieb Andrea Faulds:
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).
It also looks like C#'s named arguments.
Oh really? Good to know, I never did anything more than Hello World with C#, because I dont trust in Mono a lot on OS X ^^;
Personally as a layman I'd prefer that syntax, too. And for keywords:
You could simply put them in quotes, making is similar to the
object-syntax in JavaScript/ECMAScript. And even variable-handling would
be out of the discussion I guess:
$abc = 'class';
test(foo: "oof", bar: "rab", 'function': 'moo', $abc: 'Foobar');
Regards,
Christian Stadler
Am 12.01.2014 18:07, schrieb Kevin Ingwersen:
Am So. Jan. 12 2014 18:02:39 schrieb Andrea Faulds:
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).
It also looks like C#'s named arguments.
Oh really? Good to know, I never did anything more than Hello World with C#, because I dont trust in Mono a lot on OS X ^^;Personally as a layman I'd prefer that syntax, too. And for keywords:
You could simply put them in quotes, making is similar to the
object-syntax in JavaScript/ECMAScript. And even variable-handling would
be out of the discussion I guess:$abc = 'class';
test(foo: "oof", bar: "rab", 'function': 'moo', $abc: 'Foobar');
What if we combined two?
test(foo: "x", 'thing' => "y");
Where the : syntax is prefixed by a bare word which is the parameter
name, while the => syntax is prefixed by an expression which evaluates
to a string, which is the parameter name.
Though that might be confusing. It would be semi-consistent with
existing array syntax, and we could then also add foo: to arrays.
--
Andrea Faulds
http://ajf.me/
Patrick Schaaf wrote:
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 simply have to ask. What do you think this will actually give you productivity
wise? Personally I only see this as a totally backwards step which requires a
lot more code in every function call when if anything we should be simplifying
that area. I know I'm not the only person who does not like all this clutter and
complication, and to be honest in my case it would be yet another reason not to
upgrade from my current PHP5.4 base ... which I'm still trying to bring all the
rest of my code up to ...
Saying I do not have to use it is simply not acceptable, since like E_STRICT, it
will be used to bring in yet more changes which have to be managed later.
Certainly PHP5.6 is not the venue for such a drastic change.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Am So. Jan. 12 2014 10:52:46 schrieb Lester Caine:
I simply have to ask. What do you think this will actually give you productivity wise? Personally I only see this as a totally backwards step which requires a lot more code in every function call when if anything we should be simplifying that area. I know I'm not the only person who does not like all this clutter and complication, and to be honest in my case it would be yet another reason not to upgrade from my current PHP5.4 base ... which I'm still trying to bring all the rest of my code up to …
Personaly, I think that it makes API’s a -lot- easier. Let’s actually look at a real-life example: the Yii framework. To create a link via a PHP function, you have the following API:
CHtml::link($name, $linkInformation);
The second parameter is either an in-app route or a real url. If it is a string, it’s a real URL - if it’s an array, its a route, where $[0] contains the path, and everythign after are $_GET parameters. Now, let’s imagine how that may look like with named arguments:
CHtml::link(name:$name, url:$url)
CHtml::link(name:$name, path:$path, params:$array)
See the huge difference? A possible declaration would be:
public static function link($name, $url=null, $path, $params)
However, that’d break backwards compatibility, right? Now, we had the idea of variadics:
public static function link($name, …$linkInfo)
Voila! We get the actual array back and minimal changes are required in the actual function - and we can still use „positional“ calling.
The advantage is clearly the readability of code, and the learning curve that can be aquired with named arguments - things magically make more sense. Sure, you can memorize all the variable names. But imagine you go back to another project and see something like that:
fnc_do_something($a, $b)
In some case, you may not remember what that was - but if the arguments were named:
fnc_do_something(file:$a, lookFor:$b)
See? Now you know it’s supposed to be a file-searching function - and it may return either array or string…but maybe your mind kicked in by that time and you remember - making named arguments also a reminding help.
… At least, that is what I think about the RFC and what it can be used for and with.
Saying I do not have to use it is simply not acceptable, since like E_STRICT, it will be used to bring in yet more changes which have to be managed later.
Huh? What does it matter to your scripts whenE_STRICTis changed? o.O
Certainly PHP5.6 is not the venue for such a drastic change.
Maybe right…maybe it’ll be in PHP6 after all. After all, I swear I saw PHP5.7 testing already O.o…
Kind regards, Ingwie
Am 12.01.2014 10:50 schrieb "Lester Caine" lester@lsces.co.uk:
Patrick Schaaf wrote:
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 simply have to ask. What do you think this will actually give you
productivity wise?
Proper call-site elision of uninteresting, should-stay-at-their-defaults
arguments. Better call-site readability because the options in use will be
named explicitly.
I have four or five places in our internal codebase where the
$options-array approach is already used for these reasons, and where we
feel the pain of explicitly managing that that is nicely described in the
RFC.
best regards
Patrick
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 :)
Personally, I'm against allowing barewords to act as strings wherever
they don't - currently - clash with keywords, for two reasons:
Firstly, the concept in general is prone to errors in the programmer's
memory and the evolution of the language regarding which words are and
aren't allowed. One of the few differences between JSON and an actual
Javascript object declaration is that keys in JSON are always quoted,
and I think that was a good move on Crockford's part. People get in the
habit of using unquoted object keys in JS, and then have to dig through
the code to figure out which name some parser is choking on.
Secondly, barewords already have a specific meaning in PHP: constants.
By convention, constants are UPPER_CASE, but the engine doesn't actually
care, and array(foo => bar) is actually valid PHP, but might be
equivalent to array('six by nine' => 42), if that's what 'foo' and 'bar'
are define()d as.
I'm glad the introduction of shortened array syntax didn't change this
meaning, and am not convinced named parameters should either, unless the
syntax is chosen to always use barewords, with no variable
interpolation or ambiguity.
As an aside, what I would like to see is the end of the "if a constant
isn't declared, assume it's actually a string" fallback, which feels
like a hangover from PHP's pre-history. The fact that an undeclared
class constant is a fatal error, but an undeclared global constant is a
notice is one of those inconsistencies for which PHP is notorious.
Regards,
--
Rowan Collins
[IMSoP]
Personally, I'm against allowing barewords to act as strings wherever
they don't - currently - clash with keywords, for two reasons:Firstly, the concept in general is prone to errors in the programmer's
memory and the evolution of the language regarding which words are and
aren't allowed. One of the few differences between JSON and an actual
Javascript object declaration is that keys in JSON are always quoted,
and I think that was a good move on Crockford's part. People get in the
habit of using unquoted object keys in JS, and then have to dig through
the code to figure out which name some parser is choking on.Secondly, barewords already have a specific meaning in PHP: constants.
By convention, constants are UPPER_CASE, but the engine doesn't actually
care, and array(foo => bar) is actually valid PHP, but might be
equivalent to array('six by nine' => 42), if that's what 'foo' and 'bar'
aredefine()d as.I'm glad the introduction of shortened array syntax didn't change this
meaning, and am not convinced named parameters should either, unless the
syntax is chosen to always use barewords, with no variable
interpolation or ambiguity.As an aside, what I would like to see is the end of the "if a constant
isn't declared, assume it's actually a string" fallback, which feels
like a hangover from PHP's pre-history. The fact that an undeclared
class constant is a fatal error, but an undeclared global constant is a
notice is one of those inconsistencies for which PHP is notorious.
This is why I proposed earlier that we should make => in function calls
work identically to array syntax, such that { const bar = "foobar";
foo(bar => 3); } would be the same as foo("bar" => 3);
However, strings are quite inconvenient. So I suggest a new,
bareword-only syntax, namely the colon. foo(bar: 3); would never mean
the constant, and only mean the parameter named bar. We could then add
this syntax to array declarations: [bar: 3, "foo" => 7]
It would allow a shorter form while avoiding inconsistency with array
syntax.
--
Andrea Faulds
http://ajf.me/
This is why I proposed earlier that we should make => in function
calls work identically to array syntax, such that { const bar =
"foobar"; foo(bar => 3); } would be the same as foo("bar" => 3);However, strings are quite inconvenient. So I suggest a new,
bareword-only syntax, namely the colon. foo(bar: 3); would never mean
the constant, and only mean the parameter named bar. We could then add
this syntax to array declarations: [bar: 3, "foo" => 7]It would allow a shorter form while avoiding inconsistency with array
syntax.
The question, is, is the parser robust enough to guarantee that the
following will all be parsed correctly:
do_soap_call(namespace: 'foo');
check(if: $arriving === true, true: 'Hello', false: 'Goodbye');
$callback = array( function: function() { }, array: array( ) );
I can't think of a case off the top of my head where it would be
theoretically impossible, but that doesn't mean it would be trivial to
implement, and if there were any cases where it couldn't be used, I'd
personally much rather it didn't exist at all. (And what about secondary
parsers, e.g. syntax highlighters?)
I'm also not convinced that it's something worth having more than one
way to write, as it just makes code harder to read for new coders: will
it be obvious that [bar: 3] is the same as ['bar' => 3], but not the
same as [bar => 3], except when it is, because of "undefined constant,
assumed string" fallbacks...?
I think I'd personally lean towards using a $ to mark named parameters,
and simply not allow dynamically choosing which parameter gets passed
(that strays close to "variable variable" territory anyway, of which I'm
not a fan). If I think of the function signature "function foo($bar) {
... }", I would tend to think of the argument as "$foo" not "foo"
anyway, so it doesn't seem a stretch that "foo($bar => 3);" would mean
"call function foo(), with argument $bar set to 3".
Regards,
--
Rowan Collins
[IMSoP]
The parser would have to be taught an actual, pretty simple, condition: Perform unusual parsing between parantheses. In pseudo code, that’d be:
if(in function argument list)
if(has named parameters)
obtain, assign and pass the paraneters.
else
fall back to traditional positioned parameters.
It would also have to ignore keywords. But that means that it would have to temporarily swap T_CONSTANTS for anything that is left from the colon. OR the colon must be attached to the last character. I.e.:
copy(from: $file, to: $file); // valid.
copy(from : $file, to : $file); // may thro an error for undefined constant?
So if the parser knows when to „think different“, then I doubt that it’ll be showing off un-robustness. However, what if the closing paranthese is missing? That are things that concern me now - actual syntax errors.
Am So. Jan. 12 2014 21:58:27 schrieb Rowan Collins:
This is why I proposed earlier that we should make => in function calls work identically to array syntax, such that { const bar = "foobar"; foo(bar => 3); } would be the same as foo("bar" => 3);
However, strings are quite inconvenient. So I suggest a new, bareword-only syntax, namely the colon. foo(bar: 3); would never mean the constant, and only mean the parameter named bar. We could then add this syntax to array declarations: [bar: 3, "foo" => 7]
It would allow a shorter form while avoiding inconsistency with array syntax.
The question, is, is the parser robust enough to guarantee that the following will all be parsed correctly:
do_soap_call(namespace: 'foo');
check(if: $arriving === true, true: 'Hello', false: 'Goodbye');
$callback = array( function: function() { }, array: array( ) );I can't think of a case off the top of my head where it would be theoretically impossible, but that doesn't mean it would be trivial to implement, and if there were any cases where it couldn't be used, I'd personally much rather it didn't exist at all. (And what about secondary parsers, e.g. syntax highlighters?)
I'm also not convinced that it's something worth having more than one way to write, as it just makes code harder to read for new coders: will it be obvious that [bar: 3] is the same as ['bar' => 3], but not the same as [bar => 3], except when it is, because of "undefined constant, assumed string" fallbacks...?
I think I'd personally lean towards using a $ to mark named parameters, and simply not allow dynamically choosing which parameter gets passed (that strays close to "variable variable" territory anyway, of which I'm not a fan). If I think of the function signature "function foo($bar) { ... }", I would tend to think of the argument as "$foo" not "foo" anyway, so it doesn't seem a stretch that "foo($bar => 3);" would mean "call function foo(), with argument $bar set to 3".
Regards,
The question, is, is the parser robust enough to guarantee that the
following will all be parsed correctly:do_soap_call(namespace: 'foo');
check(if: $arriving === true, true: 'Hello', false: 'Goodbye');
$callback = array( function: function() { }, array: array( ) );
None of those would work, they're reserved words. You'd do
bar("namespace" => "foo") not bar(namespace: "foo");
--
Andrea Faulds
http://ajf.me/
Am 12.01.2014 20:31 schrieb "Rowan Collins" rowan.collins@gmail.com:
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 :)Personally, I'm against allowing barewords to act as strings wherever
they don't - currently - clash with keywords, for two reasons:
...
Secondly, barewords already have a specific meaning in PHP: constants. By
convention, constants are UPPER_CASE, but the engine doesn't actually care,
and array(foo => bar) is actually valid PHP, but might be equivalent to
array('six by nine' => 42), if that's what 'foo' and 'bar' aredefine()d as.
I completely overlooked that. You are totally right.
best regards
Patrick
On Sat, Jan 11, 2014 at 4:42 PM, Kevin Ingwersen
ingwie2000@googlemail.comwrote:
Hello there.
Within one of the recent votes, I was reminded upon an RFC for named
parameters/arguments - to be exact, this one:
https://wiki.php.net/rfc/named_paramsI just wanted to know if this RFC is still in discussion, has been
dropped, or what else is currently being up with it. Because in my opinion,
that’d be a very useful addition - as many modern languages support this
kind of feature already. The only language that I personaly am using that
supports that is Objective-C - and in there, it is very useful. Although
its quite different - it’s a different call-style entirely - I could
imagine the implementation from the link above to be very useful in PHP.It would be great to know the current state of the RFC, as I didn’t really
see anything of its current state on the page itself.
A quick summary:
The open questions are mostly resolved, namely: Variadics / unpacking on
named args should use same syntax as for not-named args. No signature
checks should be introduced, instead use runtime errors. The question of
syntax wasn't yet entirely clear, though that's something one could just
vote, if need be.
The patch itself is also finished from the "general feature implementation"
side. What is missing are updates to internal functions. Namely all arginfo
structs should be made consistent across functions and synced with the
docs. Also we need to ensure that argument parsing for internal functions
works correctly everywhere.
Feature freeze for 5.6 is in two months and the last two points require a
huge amount of work (because of the sheer number of functions in our
standard library). I started a bit on the arginfo part, by updating the
parameter names for array functions in the docs, but didn't continue that
effort as other things got in the way. I don't think I'll have enough time
to finish this before 5.6 FF.
So, likely this will be postponed to the next version of PHP ;)
Nikita
Cool! Hopefuly it’ll make it some day - that’d be very useful to have. :3
Am So. Jan. 12 2014 11:27:22 schrieb Nikita Popov:
Hello there.
Within one of the recent votes, I was reminded upon an RFC for named parameters/arguments - to be exact, this one: https://wiki.php.net/rfc/named_params
I just wanted to know if this RFC is still in discussion, has been dropped, or what else is currently being up with it. Because in my opinion, that’d be a very useful addition - as many modern languages support this kind of feature already. The only language that I personaly am using that supports that is Objective-C - and in there, it is very useful. Although its quite different - it’s a different call-style entirely - I could imagine the implementation from the link above to be very useful in PHP.
It would be great to know the current state of the RFC, as I didn’t really see anything of its current state on the page itself.
A quick summary:
The open questions are mostly resolved, namely: Variadics / unpacking on named args should use same syntax as for not-named args. No signature checks should be introduced, instead use runtime errors. The question of syntax wasn't yet entirely clear, though that's something one could just vote, if need be.
The patch itself is also finished from the "general feature implementation" side. What is missing are updates to internal functions. Namely all arginfo structs should be made consistent across functions and synced with the docs. Also we need to ensure that argument parsing for internal functions works correctly everywhere.
Feature freeze for 5.6 is in two months and the last two points require a huge amount of work (because of the sheer number of functions in our standard library). I started a bit on the arginfo part, by updating the parameter names for array functions in the docs, but didn't continue that effort as other things got in the way. I don't think I'll have enough time to finish this before 5.6 FF.
So, likely this will be postponed to the next version of PHP ;)
Nikita
Feature freeze for 5.6 is in two months and the last two points require a
huge amount of work (because of the sheer number of functions in our
standard library). I started a bit on the arginfo part, by updating the
parameter names for array functions in the docs, but didn't continue that
effort as other things got in the way. I don't think I'll have enough time
to finish this before 5.6 FF.So, likely this will be postponed to the next version of PHP ;)
Would it be possible for others to help in this effort? I really want to
see this in 5.6, and I imagine others might too.
--
Andrea Faulds
http://ajf.me/
Heya,
-----Original Message-----
From: Kevin Ingwersen [mailto:ingwie2000@googlemail.com]
Sent: Saturday, January 11, 2014 4:43 PM
To: PHP internals
Subject: [PHP-DEV] Revisiting the "Named Arguments" RFCHello there.
Within one of the recent votes, I was reminded upon an RFC for named parameters/arguments - to be exact, this one:
https://wiki.php.net/rfc/named_paramsI just wanted to know if this RFC is still in discussion, has been dropped, or what else is currently being up with
it. Because in
my opinion, that'd be a very useful addition - as many modern languages support this kind of feature already. The only
language that I personaly am using that supports that is Objective-C - and in there, it is very useful. Although its
quite
different - it's a different call-style entirely - I could imagine the implementation from the link above to be very
useful in
PHP.It would be great to know the current state of the RFC, as I didn't really see anything of its current state on the
page itself.Kind regards,
Ingwie
Since the RFC has not included my concerns so far I am going to bring them up again. The included validation of
signatures is a huge BC break and thus a no-go for PHP 5.x IMO:
http://markmail.org/message/blcph3p377x4ycmc#query:+page:1+mid:jtfa52bzgsua7yrt+state:results
http://markmail.org/message/blcph3p377x4ycmc#query:+page:1+mid:u5y2pvzttbudkxqe+state:results
Since the RFC has not included my concerns so far I am going to bring them
up again. The included validation of
signatures is a huge BC break and thus a no-go for PHP 5.x IMO:http://markmail.org/message/blcph3p377x4ycmc#query:+page:1+mid:jtfa52bzgsua7yrt+state:results
http://markmail.org/message/blcph3p377x4ycmc#query:+page:1+mid:u5y2pvzttbudkxqe+state:results
Kindly reread the RFC and my last message in this thread. The RFC states
the signature validation as an "open question" and my last mail states that
it was decided not to include signature validation. So where did you get
the idea of it being "included"?
Nikita
Hey Nikita
-----Original Message-----
From: Nikita Popov [mailto:nikita.ppv@gmail.com]
Sent: Sunday, January 12, 2014 4:49 PM
To: Robert Stoll
Cc: Kevin Ingwersen; PHP internals
Subject: Re: [PHP-DEV] Revisiting the "Named Arguments" RFCSince the RFC has not included my concerns so far I am going to bring them
up again. The included validation of
signatures is a huge BC break and thus a no-go for PHP 5.x IMO:http://markmail.org/message/blcph3p377x4ycmc#query:+page:1+mid:jtfa52bzgsua7yrt+state:results
http://markmail.org/message/blcph3p377x4ycmc#query:+page:1+mid:u5y2pvzttbudkxqe+state:results
Kindly reread the RFC and my last message in this thread. The RFC states
the signature validation as an "open question" and my last mail states that
it was decided not to include signature validation. So where did you get
the idea of it being "included"?Nikita
I did, unless it is not an error in my browser the section "open question" is empty.
I do not know which last email you mean but anyway the RFC (https://wiki.php.net/rfc/named_params) still states:
"If named parameters are introduced, signature validation should make sure that parameter names are not changed. Usually
signature mismatches between an interface and an implementing class throw a fatal error, but this is not possible in
this case due to the large BC break it would cause. Instead we could use some lower error type for this (warning /
notice / strict)."
Did you open another RFC?
I did, unless it is not an error in my browser the section "open question"
is empty.
I do not know which last email you mean but anyway the RFC (
https://wiki.php.net/rfc/named_params) still states:
"If named parameters are introduced, signature validation should make sure
that parameter names are not changed. Usually
signature mismatches between an interface and an implementing class throw
a fatal error, but this is not possible in
this case due to the large BC break it would cause. Instead we could use
some lower error type for this (warning /
notice / strict)."Did you open another RFC?
It looks like you fell into the wiki-redesign trap. The "Open questions" is
a super-heading for "Syntax", the next two headings and the "Signature
validation [...]". The new wiki design just makes the heading types so
similar in font size that they are hard to distinguish.
Nikita
Since the RFC has not included my concerns so far I am going to bring them up again. The included validation of
signatures is a huge BC break and thus a no-go for PHP 5.x IMO:
http://markmail.org/message/blcph3p377x4ycmc#query:+page:1+mid:jtfa52bzgsua7yrt+state:results
http://markmail.org/message/blcph3p377x4ycmc#query:+page:1+mid:u5y2pvzttbudkxqe+state:results
The error/warning on conflictive parameter names could be done just when
calling with named parameters.