Yo-An Lin wrote on 05/06/2015 06:51:
Laruence php.net> writes:
On Fri, Aug 30, 2013 at 11:23 PM, Nikita Popov gmail.com>
wrote:
Hi internals!
This RFC proposes to add a syntax for argument unpacking:
https://wiki.php.net/rfc/argument_unpacking
Basically, this is the "complement" of t
Laruence php.net> writes:
>
> On Fri, Aug 30, 2013 at 11:23 PM, Nikita Popov gmail.com>
> wrote:
> > Hi internals!
> >
> > This RFC proposes to add a syntax for argument unpacking:
> >
> > https://wiki.php.net/rfc/argument_unpacking
> >
> > Basically, this is the "complement" of the variadi
hi Nikita!
On Fri, Aug 30, 2013 at 5:23 PM, Nikita Popov wrote:
> Hi internals!
>
> This RFC proposes to add a syntax for argument unpacking:
>
> https://wiki.php.net/rfc/argument_unpacking
>
> Basically, this is the "complement" of the variadics RFC: It is not about
> declaring variadic func
Big +1 from me, though as Stas pointed out, multiple unpacks in a single
call don't really work with PHP parameter typing, so I'd make that use an
error.
On Sat, Aug 31, 2013 at 10:57 AM, Adam Harvey wrote:
> On 30 August 2013 08:23, Nikita Popov wrote:
> > The syntax it introduces looks as fo
On 30 August 2013 08:23, Nikita Popov wrote:
> The syntax it introduces looks as follows:
>
> $db->query($query, ...$params);
Somebody was going to do this, and it's going to be me. Sorry. We were
doing so well.
I don't like the ellipsis. I could just about deal with it for the
variadic RFC,
On 31 August 2013 03:21, Nikita Popov wrote:
>> This is very special use case to be hidden in library functions, I don't
>> think we need to have language syntax specially directed at that, at the
>> cost of making it overall more complex and hard to understand. I can see
>> what "add all those pa
On Fri, Aug 30, 2013 at 11:50 PM, Stas Malyshev wrote:
> > If staying consistent with foreach is not wanted (or this is not
> How calling a function can be consistent with foreach? Those are
> different things. Calling a function should be consistent with all other
> cases of calling a function.
Hi!
Am 31.8.2013 um 01:39 schrieb Lazare Inepologlou :
>
>
> 2013/8/31 Bob Weinand
> Hi!
>
> Am 31.8.2013 um 00:27 schrieb Lazare Inepologlou :
>
> > 2013/8/30 Stas Malyshev
> >
> >>> don't see a reason why one should explicitly disallow doing multiple
> >>> unpacks.
> >>
> >> Because it ma
Hi!
Am 31.8.2013 um 01:39 schrieb Stas Malyshev :
> Hi!
>
>> function short (...$args) {
>>if (count($args))
>>return long(...$args, "some value");
>> }
>
> This is exactly the problem. Since $args has undefined number of
> arguments, there's no way to determine where "some value" e
2013/8/31 Bob Weinand
> Hi!
>
> Am 31.8.2013 um 00:27 schrieb Lazare Inepologlou :
>
> > 2013/8/30 Stas Malyshev
> >
> >>> don't see a reason why one should explicitly disallow doing multiple
> >>> unpacks.
> >>
> >> Because it makes very hard to understand what's going on and makes no
> >> sens
Hi!
> function short (...$args) {
> if (count($args))
> return long(...$args, "some value");
> }
This is exactly the problem. Since $args has undefined number of
arguments, there's no way to determine where "some value" ends up. Which
means it's impossible to understand what's going o
Hi!
Am 31.8.2013 um 00:27 schrieb Lazare Inepologlou :
> 2013/8/30 Stas Malyshev
>
>>> don't see a reason why one should explicitly disallow doing multiple
>>> unpacks.
>>
>> Because it makes very hard to understand what's going on and makes no
>> sense semantically.
>>
>>> As you can see, he
Hi!
> Not sure I get what you mean. All languages with argument unpacking
> allow this. It's not commonly needed, but there are uses for it and I
I mean this:
>>> a = [0,3]
>>> range(*a)
[0, 1, 2]
>>> a = [1]; b = [2]
>>> range(*a, *b)
File "", line 1
range(*a, *b)
^
SyntaxE
2013/8/30 Stas Malyshev
> > don't see a reason why one should explicitly disallow doing multiple
> > unpacks.
>
> Because it makes very hard to understand what's going on and makes no
> sense semantically.
>
> > As you can see, here two arguments are unpacked in one call.
>
> This is very special
Hi!
> This RFC proposes to add a syntax for argument unpacking:
>
> https://wiki.php.net/rfc/argument_unpacking
>
> Basically, this is the "complement" of the variadics RFC: It is not about
> declaring variadic functions, but about calling them.
This is just another way of doing call_user_f
On 08/30/2013 05:23 PM, Nikita Popov wrote:
Hi internals!
This RFC proposes to add a syntax for argument unpacking:
https://wiki.php.net/rfc/argument_unpacking
Basically, this is the "complement" of the variadics RFC: It is not about
declaring variadic functions, but about calling them.
On Fri, Aug 30, 2013 at 11:23 PM, Nikita Popov wrote:
> Hi internals!
>
> This RFC proposes to add a syntax for argument unpacking:
>
> https://wiki.php.net/rfc/argument_unpacking
>
> Basically, this is the "complement" of the variadics RFC: It is not about
> declaring variadic functions, but
On Fri, Aug 30, 2013 at 7:45 PM, Stas Malyshev wrote:
> Hi!
>
> > Assuming you mean call_user_func_array, yes. This is just syntax sugar
> > for call_user_func_array. Advantages of this syntax over cufa are
> > outlined here:
> >
> https://wiki.php.net/rfc/argument_unpacking#advantages_over_call_u
2013/8/30 Stas Malyshev
> Hi!
>
> > This RFC proposes to add a syntax for argument unpacking:
> >
> > https://wiki.php.net/rfc/argument_unpacking
> >
> > Basically, this is the "complement" of the variadics RFC: It is not about
> > declaring variadic functions, but about calling them.
>
> Thi
Hi internals!
This RFC proposes to add a syntax for argument unpacking:
https://wiki.php.net/rfc/argument_unpacking
Basically, this is the "complement" of the variadics RFC: It is not about
declaring variadic functions, but about calling them.
The syntax it introduces looks as follows:
2013/8/30 Stas Malyshev
> Hi!
>
> > A good example would be function forwarding for variadic functions,
> > without resorting to call_user_func_array.
>
> What's wrong with "resorting to" call_user_func_array?
> call_user_func_array is a PHP function and not some dark magic that one
> should avoi
Hi!
> A good example would be function forwarding for variadic functions,
> without resorting to call_user_func_array.
What's wrong with "resorting to" call_user_func_array?
call_user_func_array is a PHP function and not some dark magic that one
should avoid using unless it is absolutely must.
-
Hi!
> Assuming you mean call_user_func_array, yes. This is just syntax sugar
> for call_user_func_array. Advantages of this syntax over cufa are
> outlined here:
> https://wiki.php.net/rfc/argument_unpacking#advantages_over_call_user_func_array
The only case that I see that could make sense is $d
On Fri, Aug 30, 2013 at 6:57 PM, Stas Malyshev wrote:
> And something like:
> test(1, 2, ...[3, 4], 5, 6, ...[7, 8])
>
> looks plain weird. What would be the use case for doing something like
> that?
No use case at all. This is a technical specification, so I write down what
is possible, not nec
On Fri, Aug 30, 2013 at 10:33 AM, Laruence wrote:
> On Fri, Aug 30, 2013 at 11:23 PM, Nikita Popov
> wrote:
> > Hi internals!
> >
> > This RFC proposes to add a syntax for argument unpacking:
> >
> > https://wiki.php.net/rfc/argument_unpacking
> >
> > Basically, this is the "complement" of t
25 matches
Mail list logo
