On Sat, Jan 11, 2014 at 4:42 PM, Kevin Ingwersen
<
[email protected]>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.
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
Afternoon Nikita,
Last time we nattered about this RFC you mentioned that you were holding off to see how engine exceptions went and that you would have preferred to finish the implementation with engine exceptions merged.
I'm just wondering if that is still the case ??
If there's much to be done to make it a reality, if you put up a list of things that need doing somewhere I'll take a stab at helping out, if you like.
Cheers
Joe