[RFC] [VOTE] Parameter skipping RFC

php.internals

Stas Malyshev

11 years ago
Hi! I'd like to announce a vote on parameter skipping RFC: https://wiki.php.net/rfc/skipparams TLDR: it allows using "default" to specify that parameter has the default value when calling function with optional parameter, like this: create_query("deleted=0", "name", default, /*report_errors*/ true) The implementation is mostly finished, there may be some things needed for merging etc. or small improvements, but I'd like to have a vote on general concept first. The vote is straight yes/no vote, and closes in 2 weeks from now. Thanks,
-- Stas Malyshev smalyshev@gmail.com

Pascal MARTIN

11 years ago
Le 08/02/2015 09:14, Stanislav Malyshev a écrit :
> I'd like to announce a vote on parameter skipping RFC: > https://wiki.php.net/rfc/skipparams
Hi, After discussing this RFC with other people at AFUP, we would be -1. Basically, even though not having to specify the default-value for some parameters could be useful in some situations, this approach doesn't "feel right" and we would really prefer something like named-parameters (even if this RFC is not incompatible with named-parameters and they most likely won't make it for PHP 7.0). Thanks
-- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/

Paul Dragoonis

11 years ago
I see a LOT of "no" votes against this RFC but can't find the thread outlining the reasoning for such resistence. Could someone link me to this somehow? On Sat, Feb 21, 2015 at 1:43 PM, Pascal Martin, AFUP < mailing@pascal-martin.fr> wrote:

Stas Malyshev

11 years ago
Hi!
> I see a LOT of "no" votes against this RFC but can't find the thread > outlining the reasoning for such resistence.
I think my attempts to explain that this was a step towards named params, not a contradiction with them, failed - people read it, say "we understood it" and the say "no, we don't want it, we want named params instead!". Well, let's hope somebody (not me) writes a patch for named params instead. In the meantime, 7.0 will have neither.
-- Stas Malyshev smalyshev@gmail.com