Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68765
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.113 as permitted sender)
Message-ID: <BLU0-SMTP4110E87ADD325FE1C6300D7E2350@phx.gbl>
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
In-Reply-To: <CAMyk_AY=pRPxcOj7F3f-kLJ-nenDdX=kJr5WgcHPO-fuCTOYAQ@mail.gmail.com>
Date: Sat, 31 Aug 2013 00:57:37 +0200
CC: Developers List PHP Mailing <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
References: <CAF+90c_Ld1BAaj2kd+hhdNkcbj6Mar2EZSYPJaSFWqmV_tb=Xw@mail.gmail.com> <5220CEDE.8080600@sugarcrm.com> <CAF+90c_d4i0XC7d76_zfE6YLgEi_J2wv-F+kdtSCySsOSSw=9g@mail.gmail.com> <5220DA50.9020306@sugarcrm.com> <CAF+90c_iZqf0Di4hH49EW4ZYG=aHQ3Z2sU6aa6KU0cs5tjd6iQ@mail.gmail.com> <522113B1.8000605@sugarcrm.com> <CAMyk_AY=pRPxcOj7F3f-kLJ-nenDdX=kJr5WgcHPO-fuCTOYAQ@mail.gmail.com>
To: Lazare Inepologlou <linepogl@gmail.com>,
 Malyshev Stas <smalyshev@sugarcrm.com>
Subject: Re: [PHP-DEV] [RFC] Argument unpacking
From: bobwei9@hotmail.com (Bob Weinand)

Hi!

Am 31.8.2013 um 00:27 schrieb Lazare Inepologlou <linepogl@gmail.com>:

> 2013/8/30 Stas Malyshev <smalyshev@sugarcrm.com>
>=20
>>> don't see a reason why one should explicitly disallow doing multiple
>>> unpacks.
>>=20
>> Because it makes very hard to understand what's going on and makes no
>> sense semantically.
>>=20
>>> As you can see, here two arguments are unpacked in one call.
>>=20
>> 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 params at the end" syntax mean. However having
>> something like ($a, ...$b, $c, ...$d, $e, $f, $g, ...$h) I have no =
idea
>> what's going on at all and what is sent where.
>>=20
>>=20
> I agree with Stas here. If an argument comes after an unpacked array, =
its
> position is not certain until runtime. This makes life difficult for =
static
> analysis tools, which is one of the reasons for introducing the new =
syntax.

The alternative is for users to use what we have now: =
call_user_func_array
with some array_merge, which makes it as difficult for static analysis =
as the
new syntax does. This really is a non-argument.

And should we really restrict the user's code with some arbitrary =
limits?
It just makes the user use some really ugly hacks nobody wants to see.

> Even in the use case of Nikita, the two arguments to be unpacked come
> without any standard arguments between or after them.
>=20
> I suggest that argument unpacking should be limited to the last =
arguments
> only.

An example where it really would make sense is:

function long ($arg, $arg2, $arg3, $arg4, $arg5, $arg6, $arg7, $string) =
{
    // do something with your arguments
}

// just instead of copying the seven parameters; increases readability
// and don't argue this would be badly statically analyzable - it is, =
but this isn't
// the point. I want to show that people may find here some use case.
function short (...$args) {
    if (count($args))
        return long(...$args, "some value");
}

> Lazare Inepologlou
> Ing=E9nieur Logiciel
>=20
>=20
>=20
> --
>> Stanislav Malyshev, Software Architect
>> SugarCRM: http://www.sugarcrm.com/
>> (408)454-6900 ext. 227

I finally am in favor of the proposal, because it allows removing a lot =
of ugly
call_user_func_array calls which aren't really well readable. (and =
naturally
because it allows passing the variadic parameters if that rfc will be =
accepted)

And I think you are really arguing about non-issues.
Example: Multiple uses of unpacking syntax makes sense when you call a
function with a variadic parameter:

function variadic (...$args) {
    // do something
}=20

variadic(...$array1, ...$array2);


Bob Weinand