[RFC] Skipping parameters take 2

On Mon, Sep 2, 2013 at 9:41 AM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:

Hi, For me as a user it would make much more sense to have named parameters then typing default. Default also feels a bit strange to type. What if I miss one default in the line? Or in the other proposal here, what if I miss one comma? Named parameters would also solve a problem from another RFC that's being proposed right now if I understand correctly so why not go for that? Kind regards ---- Florin Patan https://github.com/dlsniper http://www.linkedin.com/in/florinpatan

On Mon, Sep 2, 2013 at 9:41 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

another small advantage would be that IDEs could show you the default value for the argument when hovering the default keyword.

On Mon, Sep 2, 2013 at 2:11 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

Hi Stanislav I would not agree with your argument that it should be introduced because it is requested by real people for years and it is simple to add. Isn't that pretty much the same as "because we can"? IMO we should wait with this RFC if Nikita is willing to write an RFC for named parameters including an implementation afterwards, because I think named parameters would address the problem way better. The skipping parameters as in your proposal would then just be the ugly alternative. However, if the RFC for named parameters will not be created or rejected, then I would appreciate your RFC. Best, Robert -----Ursprüngliche Nachricht----- Von: Stas Malyshev [mailto:smalyshev@sugarcrm.com] Gesendet: Montag, 2. September 2013 22:12 An: Nikita Popov Cc: PHP Internals Betreff: Re: [PHP-DEV] [RFC] Skipping parameters take 2 Hi!

I don't understand. Who says I should do that? I certainly don't see how I should.

If you are ready to present named args proposal for 5.6, fine. But if not, I think denying obviously requested feature (see links for requests in the RFC) because some "pie in the sky" consideration is completely wrong. I must say it seems a little strange for me given current stream of "because we can" syntax additions proposed to reject something that has been asked for by real people for years just because sometime in the future we might or might not have something that may do a similar thing in different way.

because it

lolwut, you're kidding right? So you listed a bunch of StackOverflow questions asking for this and from this concluded that this is a feature "people need" whereas the RFCs by ircmaxell/me (whichever you mean) are not needed and are proposed just "because we can" and are not needed by "real people"? Would you like RFC's to include detailed chat logs, Twitter mentions and Reddit conversations as proof that features are wanted by "real people"? Nikita

On Mon Sep 2 08:52 AM, Sebastian Krebs wrote:

Lots of overlap between variadic functions, this proposal & named parameters. A popular use case for library authors is to use: interface foo { function formatUseCases(array $options); } - Advantage: No dependency on a class / object - Disadvantage: doesn't document what options are available, hard to extend 'default parameters' interface foo { function formatUseCases(MyOptions $options); } - Advantage: documents which options are available, easy to extend default parameters - Disadvantage: modification of the object means these 'options' are available to any declaration using it, hard to maintain over time without big refactoring (lots of options objects) interface foo { function formatUseCases(...$options); } - Advantage: No dependency on a class / object - Disadvantage: doesn't document what options are available, no default parameters interface foo { function formatUseCases($showGood = true, $showBad = true, $pretty = true, $title= "what are these parameters?"); } - Advantage: Self-documenting with default parameters - Disadvantage: Not extendable api signature (changing default parameters) - Readability: # array formatUseCases(['showGood': true, 'showBad': true, 'pretty': true]); #object $obj->showGood = true; $obj->showBad = true; $obj->pretty = true; formatUseCases($obj); # variadic or function declaration formatUseCases(true, true, true, "what are these parameters?"); - Solution somewhat as a hybrid? interface foo { function formatUseCases(...$options[showGood = true, showBad = true, pretty = true, title= "what are these parameters?"]); } formatUseCases(true, true, true, "use defaults for everything else"); formatUseCases(['title': "use defaults for everything else"]); // more readable Implemention wise $options could be ~ SplParameters which implements ArrayInterface : class bar implements foo { function formatUseCases(...$options[]) { // api signature as $options[] always accepted (uses default params) echo get_class($options); // SplParameters var_dump($options['showGood']) // true; var_dump($options->showGood) // true; } } class bar2 implements foo { function formatUseCases(...$options[showGood = false]) { // easy to extend default options var_dump($options['showGood']) // false; } } Why use special syntax ~ "...$options[]" instead of just named parameters: http://msdn.microsoft.com/en-us/library/dd264739.aspx My hunch is that applying named parameters to every function would be very costly in PHP. But as a special syntax applied to a few functions, this might work well.

On Mon, Sep 2, 2013 at 10:19 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

I already have a mostly-working implementation for named arguments and unless I missed something critical it does not require us to redo argument passing. The idea I followed was to keep the argument passing pretty much as-is, just instead of always pushing on top of the stack to place named args directly at the correct offsets. So we still have a stack of positional arguments, they're just inserted out of order. This will also leave NULL values in between, so they need to be handled as in your implementation. The only thing you can't handle this way are named arguments that are not defined in the signature - if we want something like pythons **kwargs those need to be collected in an HT. I'd likely not support that at first, land basic named args instead and then seek to merge kwargs into the RFC's for variadics/unpacking. Nikita

Am 14.01.2015 um 20:21 schrieb Adam Harvey:

OMG you are right - my fault

That would be a BC break as you can currently have a constant _. An existing keyword makes upgrading easier, and default is easier to understand by someone who doesn’t know about the feature than an underscore. --- Simon Welsh Admin of http://91carriage.com/ – Specialised SilverStripe hosting

Hi!

Strike that, I was confused, for some reason I thought I've already put it to vote, even though I've put to vote my other RFC (shameless plug: https://wiki.php.net/rfc/default_ctor, go there and vote Yes ;). Too many RFCs :) So I'll think if it's easy to add and maybe add it before it goes to vote.

Hi Stas,

it's possible to do

This would be quite a nice feature, even if this RFC does not pass. Just as hint, there are ambiguous case which need to be considered: interface A{ function foo($a=1); } interface B{ function foo($a="hi"); } class C implements A, B{ function foo($a=default){} //what would be the default value? } Cheers, Robert