Hi,
I was only loosely following the discussion about this topic, so please
flame me if I got this wrong;)
I tend use the array-alternative alot which fits my purposes nicely
except for default-values. If named-parameters are introduced in this
proposed way, I don't see any advantages other than that it's official
syntax.
As I understood it wouldn't be more efficient, since it would actually
be just like an optional array parameter, automatically added.
Also if I have to use func_get_args to access those values, and they
will be mixed with the non optional args I don't think I'd actually
adopt this new syntax.
As I am using it now:
function foo($x,$y,$options=array()){
if ( !isset($options['opt1']) ) $options['opt1'] = 'foo';
if ( !isset($options['opt2']) ) $options['opt2'] = 'bar';
/* 1 */
}
foo(1,2);
foo(1,2,array('opt1'=>'no-foo'));
Proposed new syntax of this case:
function foo($x,$y){
$options = func_get_args();
if ( !isset($options['opt1']) ) $options['opt1'] = 'foo';
if ( !isset($options['opt2']) ) $options['opt2'] = 'bar';
/* 1 */
}
foo(1,2);
foo(1,2,'opt1'=>'no-foo');
This does not provide anything new to me as a programmer and even
introduces a non-selfdocumenting behaviour ($options is not in the
function-header) so the user has to *know* about the possibility of
passing any options.
What would really assist me in a self-documenting manner would be the
possibility to specify default values for those options in the function
header, which could also act as a filter.
something like:
function foo($x,$y,$options=(
'opt1'=>'foo',
'opt2'=>'bar'
)){
/* 1 */
}
foo(1,2);
foo(1,2,'opt1'=>'no-foo','opt3'=>'unspecified-option'); //opt3 will not
be within $options.
This would provide me with something which implicitly handles
default-values, defines which options can be passed and filters out
options which are not allowed. $options could be an array or a stdObject.
Personally I'd prefer a wrapping of any given optional parameters like:
foo(1,2,('opt1'=>'no-foo'));
This would even allow for multiple optional-parameter-lists.
foo(1,2,('opt1'=>'no-foo'),('other'=>'some'));
The advantage of such a mechanism shows wehn the second list is passed
on to a second function.
function foo($x,y,$options=(
'opt1'=>'foo',
'opt2'=>'bar'
),$more=(
'other'=>'ok',
'more'=>'x',
)){
/* 1 */
bar($more);
}
function bar($options=(
'other'=>'ok',
'more'=>'x',
)){
/* 2 */
}
Although I have to admit that the filtering would hamper the
extendability becaues foo() would filter out valid options for bar().
This could be mitigated by introducing the ... syntax. (ex. $more=...)
No offense. Just my (probably naive) thinking while reading this thread.
Cheers!
Lars
PS: Also, what do you guys think of an additional (optional) possibility:
function myFunc($a, $b, ...$options) // sort of like Java
and this way $options can be filled, so people don't have to keep
using func_get_args to get all the arguments.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
