RE: [PHP-DEV] [RFC] Skipping parameters take 2

From: Date: Mon, 02 Sep 2013 16:04:11 +0000
Subject: RE: [PHP-DEV] [RFC] Skipping parameters take 2
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
On Mon Sep 2 08:52 AM, Sebastian Krebs wrote:
> 2013/9/2 Pierre Joye <[email protected]>
> 
> > >
> > > Any comments or feedback on the RFCs and the code are welcome,
> > > especially pointing out the cases where it may not work (which means
> > > we need more phpt's there :)
> >
> > Using default instead of ,,, is indeed much more readable.
> >
> > However I still wonder what prevents to finally implement named
> > parameters too, it will provide the same feature while being even more
> > handy and easier.
> 
> 
> And it covers an additional use-case: Self-explaning parameters like in
> "foo(is_strict = false)" instead of "foo(null, null, false)".
> 
> 

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.



Thread (69 messages)

« previous php.internals (#68853) next »