Hello.
Take the following simple code.
<?php
function foo($var1, $var2 = 2, $var3 = 3) {
echo "$var1, $var2, $var3\n";
}
foo(10); // 10, 2, 3
foo(10, 20); // 10, 20, 3
foo(10, 20, 30); // 10, 20, 30
foo(10, null, 30); // 10, , 30
foo(10,, 30); // Parse error.
?>
According to the manual
A variable is considered to be null if it has not been set to any value yet [1].
By default, function arguments are passed by value [2].
When using default arguments, any defaults should be on the right side
of any non-default arguments. [3]
From this, the question I have is what do I pass when I want to use
the default, WITHOUT having to supply the default value itself.
On the surface, null should work. Null (according to [1]) is
specifically saying that there is no value. But it is being
interpreted as a value.
I'm guessing the reason for null being interpreted as a value is
really that the supplied argument count is used and any unsupplied
arguments are defaulted.
But null isn't a value ... that seems to be REALLY important to me.
But from userland it is a value. Just a really odd one.
I would argue that by having a null in the arguments, the intent is to
NOT supply a value and have the default value used in the function.
Possible solutions.
1 - Do nothing in core and implement is_null() checking to reinstate
the default value.
function foo($var1, $var2 = 2, $var3 = 3) {
$var2 = is_null($var2) ? 2 : $var2;
$var3 = is_null($var3) ? 3 : $var3;
echo "$var1, $var2, $var3\n";
}
2 - Allow null to be supplied and have the default value be used for
the argument.
foo(10, null, 30); // would output 10, 2, 30
3 - New keyword of default or void to specifically indicate the intent
to use the default value for the argument.
foo(10, default, 30); // would output 10, 2, 30
4 - Allow missing arguments to default.
foo(10,, 30); // Parse error.
Option 4 would probably be the worse one to go for. Looking any number
of languages that support defaults and you will see code like ...
someFunction(param1,,,,,param7,,,,param11)
sort of thing.
Option 3, whilst does clearly indicate the intent, does introduce a
new keyword. As a non core dev, I'm guessing we end up with naming
conflicts. And something called "default" is probably going to be a
big one. "Void" also.
But using something like _ (yep, underscore), could be a solution here [4].
Option 2, after probably having to reject option 3, would be my
choice. I want null to REALLY mean nothing. Just like it would be in
foo(10).
Option 1 is what I have to do at the moment.
Regards,
Richard.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
[1] http://docs.php.net/manual/en/language.types.null.php
[2] http://docs.php.net/manual/en/functions.arguments.php#functions.arguments.by-reference
[3] http://docs.php.net/manual/en/functions.arguments.php#functions.arguments.default
[4] http://www.seoegghead.com/software/php-parameter-skipping-and-named-parameters.seo
foo(10,, 30); // Parse error.
I thought this used to work...
I would argue that by having a null in the arguments, the intent is to
NOT supply a value and have the default value used in the function.
Unfortunately, no.
There are times when I want to over-ride the default, and shove NULL
in as the value...
1 - Do nothing in core and implement
is_null()checking to reinstate
the default value.
I believe that this is probably Best Practice in current PHP.
Validate your incoming parameters consistent with the intent of the
code-base in question.
2 - Allow null to be supplied and have the default value be used for
the argument.foo(10, null, 30); // would output 10, 2, 30
-1
3 - New keyword of default or void to specifically indicate the intent
to use the default value for the argument.foo(10, default, 30); // would output 10, 2, 30
This seems reasonable to me.
4 - Allow missing arguments to default.
foo(10,, 30); // Parse error.
Also reasonable.
I'd even say both 3&4 together are in keeping with PHP spirit, to
allow the lazy scripters to use 10,,30 and the formal developers to
use DEFAULT.
Option 4 would probably be the worse one to go for. Looking any number
of languages that support defaults and you will see code like ...someFunction(param1,,,,,param7,,,,param11)
It does get ugly fast for large numbers of arguments...
But any function with more than a handful of arguments is already
asking for trouble...
At that point you should be passing in a data structure / instance /
array or something other than so many parameters.
Perhaps a constant like PHP_DEFAULT rather than a new "keyword"?
But using something like _ (yep, underscore), could be a solution here
[4].
Icky. :-)
Option 2, after probably having to reject option 3, would be my
choice. I want null to REALLY mean nothing. Just like it would be in
foo(10).
Alas, NULL behaves more like an actual value sometimes, depending on
which functions you use...
isset versus array_key_exists, for example.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
Option 4 would probably be the worse one to go for. Looking any number
of languages that support defaults and you will see code like ...someFunction(param1,,,,,param7,,,,param11)
It does get ugly fast for large numbers of arguments...
But any function with more than a handful of arguments is already
asking for trouble...At that point you should be passing in a data structure / instance /
array or something other than so many parameters.
The above example would have at least 10 arguments, so I'd also say it'd
look bad never mind the syntax.
Also a subtle thing: if your email reader doesn't use fixed width font, it's
hard to appreciate the look of each approach in an actual code editor.
And I'd say commas next to each other appear quite readable, self-sufficient
in fixed-width font, not to mention self-explanatory.
Using 'default' would raise more confusion, such as, is that valid: $foo =
default; bar($foo);
If it's made valid, i.e. if it acts as a constant, I suspect before long
people will be assigning 'default' as yet another alternative to a
false/null value, and we'll need yet another concept to resolve that.
If it's not made valid, it'll be counter-intuitive as it looks exactly like
a constant passed as an argument.
Stan Vass
Option 4 would probably be the worse one to go for. Looking any number
of languages that support defaults and you will see code like ...someFunction(param1,,,,,param7,,,,param11)
It does get ugly fast for large numbers of arguments...
But any function with more than a handful of arguments is already
asking for trouble...At that point you should be passing in a data structure / instance /
array or something other than so many parameters.The above example would have at least 10 arguments, so I'd also say it'd
look bad never mind the syntax.Also a subtle thing: if your email reader doesn't use fixed width font, it's
hard to appreciate the look of each approach in an actual code editor.
And I'd say commas next to each other appear quite readable, self-sufficient
in fixed-width font, not to mention self-explanatory.Using 'default' would raise more confusion, such as, is that valid: $foo =
default; bar($foo);
If it's made valid, i.e. if it acts as a constant, I suspect before long
people will be assigning 'default' as yet another alternative to a
false/null value, and we'll need yet another concept to resolve that.
If it's not made valid, it'll be counter-intuitive as it looks exactly like
a constant passed as an argument.Stan Vass
I'm not only talking about userland code here.
There are MANY functions in PHP that utilise default parameters.
In most cases the lesser used parameters are at the end of the
parameter list and it more often than not, it makes sense to supply
the preceding parameters.
Yes, I know a bunch of commas, one after the other, is unreadable.
I've seen VBA code!
I want null to be null. Not to be interpreted as a value. If I pass a
null to a function with a default, I'm specifically NOT setting the
value. Null has no value. The default is the only option that should
be used.
This can only apply to scalars. Objects, resources and arrays should
all have the =null option.
I'm guessing that the issue with implementing this in core is that
each function is responsible for the defaults in such a way that they
cannot easily be abstracted to the parameter processing code.
The parameter values are first set to their defaults and then
overwritten by the parameter processing code.
I think that, for scalars, if I've supplied null, there is no value to
overwrite.
Take this example. This is the first function in the manual that has
an optional parameter.
int apc_bin_dumpfile ( array $files , array $user_vars , string
$filename [, int $flags [, resource $context ]] )
Arguments that have been raised about too many parameters ... how many
is too many? Is 5 OK? Why not x?
$flags has no default here, but it is an int, so I have to assign
something (well, I don't the default is 0 and the documentation is out
on this issue, but that's another issue).
So, off I go read the manual to be redirected to another page to get
the list of flags I can 'OR'.
But, assuming the default was documented, the prototype would look
more like int $flags = 0
So, I want to use the default. OK. 0 vs null in terms of code, 0 is
shorter, but it means that if the default was to change (not with this
function, but any function - and that could be userland), then
allowing me to say "use whatever the default is" would certainly be
the way to protect me.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
Hi!
3 - New keyword of default or void to specifically indicate the intent
to use the default value for the argument.
Actually, 'default' is already a keyword (switch!), while _ is an actual
function name (gettext). So default, syntactically, can work, while _
can't.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Yup. I'm leaning towards Richard's idea of a predefined constant rather
than a new keyword which would effectively do the same thing. The only
issue I can see coming out of using the constant would be it's represented
value. If a compile-time keyword were used, at least it could be caught
there without running into any value clashing issues.
-----Original Message-----
From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
Sent: Wednesday, October 20, 2010 1:37 PM
To: RQuadling@googlemail.com
Cc: Richard Quadling; PHP internals
Subject: Re: [PHP-DEV] Skipping of defaulted parameters.
Hi!
3 - New keyword of default or void to specifically indicate the intent
to use the default value for the argument.
Actually, 'default' is already a keyword (switch!), while _ is an actual
function name (gettext). So default, syntactically, can work, while _
can't.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hello.
Take the following simple code.
<?php
function foo($var1, $var2 = 2, $var3 = 3) {
echo "$var1, $var2, $var3\n";
}foo(10); // 10, 2, 3
foo(10, 20); // 10, 20, 3
foo(10, 20, 30); // 10, 20, 30
foo(10, null, 30); // 10, , 30
foo(10,, 30); // Parse error.
?>According to the manual
A variable is considered to be null if it has not been set to any value yet [1].
By default, function arguments are passed by value [2].
When using default arguments, any defaults should be on the right side
of any non-default arguments. [3]From this, the question I have is what do I pass when I want to use
the default, WITHOUT having to supply the default value itself.On the surface, null should work. Null (according to [1]) is
specifically saying that there is no value. But it is being
interpreted as a value.I'm guessing the reason for null being interpreted as a value is
really that the supplied argument count is used and any unsupplied
arguments are defaulted.But null isn't a value ... that seems to be REALLY important to me.
But from userland it is a value. Just a really odd one.I would argue that by having a null in the arguments, the intent is to
NOT supply a value and have the default value used in the function.Possible solutions.
1 - Do nothing in core and implement
is_null()checking to reinstate
the default value.function foo($var1, $var2 = 2, $var3 = 3) {
$var2 = is_null($var2) ? 2 : $var2;
$var3 = is_null($var3) ? 3 : $var3;
echo "$var1, $var2, $var3\n";
}2 - Allow null to be supplied and have the default value be used for
the argument.foo(10, null, 30); // would output 10, 2, 30
3 - New keyword of default or void to specifically indicate the intent
to use the default value for the argument.foo(10, default, 30); // would output 10, 2, 30
4 - Allow missing arguments to default.
foo(10,, 30); // Parse error.
Option 4 would probably be the worse one to go for. Looking any number
of languages that support defaults and you will see code like ...someFunction(param1,,,,,param7,,,,param11)
sort of thing.
Option 3, whilst does clearly indicate the intent, does introduce a
new keyword. As a non core dev, I'm guessing we end up with naming
conflicts. And something called "default" is probably going to be a
big one. "Void" also.But using something like _ (yep, underscore), could be a solution here [4].
Option 2, after probably having to reject option 3, would be my
choice. I want null to REALLY mean nothing. Just like it would be in
foo(10).Option 1 is what I have to do at the moment.
Option 5: Implement named parameters?
--
Ionuț G. Stan | http://igstan.ro
Option 5: Implement named parameters?
Option 6: do as other have and just pass an array yourself...
On Thu, Oct 21, 2010 at 12:52 AM, Ionut G. Stan ionut.g.stan@gmail.com
wrote:Option 5: Implement named parameters?
Option 6: do as other have and just pass an array yourself...
--
With #6, you would lose the argument hinting(either be native, or phpdoc)
feature for your method.
Tyrael
With #6, you would lose the argument hinting(either be native, or phpdoc)
feature for your method.
you would, however
a) it's already supported
b) there's no language changes required
c) do your own typecasting, sanity checking, bounds checking, etc.
inside of the function
i put an example in another email.
Option 5: Implement named parameters?
Come on, play fair. I know all about the named parameters and I didn't
mention them.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
Option 5: Implement named parameters?
Come on, play fair. I know all about the named parameters and I didn't
mention them.
Where's the unfairness? I proposed them because the issue you raised is
a perfectly valid reason to introduce named parameters. IMO.
--
Ionuț G. Stan | http://igstan.ro
On 21 October 2010 08:52, Ionut G. Stanionut.g.stan@gmail.com wrote:
Option 5: Implement named parameters?
Come on, play fair. I know all about the named parameters and I didn't
mention them.Where's the unfairness? I proposed them because the issue you raised is a
perfectly valid reason to introduce named parameters. IMO.
Because for the last few days, named parameters have been discussed.
Again. And with the same result. Not yet (and maybe not ever) for PHP.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
Option 5: Implement named parameters?
Come on, play fair. I know all about the named parameters and I didn't
mention them.Where's the unfairness? I proposed them because the issue you raised is a
perfectly valid reason to introduce named parameters. IMO.Because for the last few days, named parameters have been discussed.
Again. And with the same result. Not yet (and maybe not ever) for PHP.
This wasn't a real discussion. Most of the contra-replies were of the
"RTFM and no" kind.
The last reference (
www.php.net/~derick/meeting-notes.html#named-parameters ) doesn't
explain either. (It just says it'd violate PHP's KISS principle. But
function calls with a ton of NULLs or array parsing isn't exactly simple
either.)
Although, there aren't any RFCs for the feature, so maybe you're right,
there's nothing to discuss.
Pas