On 13.04.2010, at 23:39, GM wrote:
> Personally, I would strongly prefer the caller syntax my_func('a', 'b', 'c'
> => 'd', $e => $f) just to because
>
> 1) it's consistent with array declaration syntax
> 2) it allows arbitrary names for parameters, which will become the
> array key
Personally, I would strongly prefer the caller syntax my_func('a',
'b', 'c' => 'd', $e => $f) just to because
1) it's consistent with array declaration syntax
2) it allows arbitrary names for parameters, which will become the
array keys ... and can include funny characters
3) naked
On 13.04.2010 01:30, Pierre Joye wrote:
> On Tue, Apr 13, 2010 at 1:28 AM, Stanislav Malyshev wrote:
>
>> I think that's the idea in general, now how it looks like - be it 'opt1' =>
>> 'no-foo' or opt1: 'no-foo' - that's the decision we need to take. I
>> personally still don't have the favorite,
On Tue, Apr 13, 2010 at 1:28 AM, Stanislav Malyshev wrote:
> I think that's the idea in general, now how it looks like - be it 'opt1' =>
> 'no-foo' or opt1: 'no-foo' - that's the decision we need to take. I
> personally still don't have the favorite, but in every case we still have
> the full par
Hi!
I think the idea is to do:
function foo($x,$y, $opt1 = 'foo', $opt2 = 'bar'){
}
foo(1,2);
foo(1,2,'opt1'=>'no-foo');
That's the idea if we can't do (1, opt1 = 'foo') or?
I think that's the idea in general, now how it looks like - be it 'opt1'
=> 'no-foo' or opt1: 'no-foo' - that's the
On Tue, Apr 13, 2010 at 1:10 AM, Stanislav Malyshev wrote:
> Hi!
>
>> 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 */
>>
Hi!
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 */
}
I think the idea is to do:
function foo($x,$y, $opt1 = 'foo', $opt2 = 'bar'){
}
Lars Schultz wrote:
> 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 */
> }
One little trick you can use to make things a bit more elegant right
I may be getting mixed-up between declared and named parameters (which
would allow for out-of-order and skipping parameters) vs. undeclared
and named additional parameters (extra junk supplied - with names -
outside of any documentation).
Either way, anything that I've not declared in the prototyp
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
On 12 April 2010 13:42, Gregory wrote:
> 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.
If
Okay, so it seems to me based on the discussion, that if we implement
named parameters the following way, it should work well:
1) Allow named parameters in function calls, using the syntax func($a,
$b, 'var1' => $value, $var2 => $value2), similar to array() definition.
2) Do not allow non-nam
> From: Christian Schneider [mailto:[EMAIL PROTECTED]
> >> Argh! Reading such a line, I think of named parameters,
> not an array.
>
> That's exactly what we are emulating this way ;-)
> Our patch is greedy, i.e. it collects as much as possible
> into one array. If you want to do this you nee
Richard Quadling wrote:
>> Argh! Reading such a line, I think of named parameters, not an array.
That's exactly what we are emulating this way ;-)
> I agree with Francois here. Other than looking STRONLY like named
> parameters, surely there is a flaw if a declaration is ...
>
> function convert
Lukas Kahwe Smith wrote:
Named parameters is not just syntax sugar, as they would make it
possible to get compiler errors and phpoc support automatically over
having to implement some array based solution to trigger errors and some
Not 'our' way of named parameters where the main feature is t
15 matches
Mail list logo
