On Mon Sep 2 08:52 AM, Sebastian Krebs wrote:
> 2013/9/2 Pierre Joye <pierre....@gmail.com>
>
> > >
> > > 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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
