Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68772
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.77 as permitted sender)
Message-ID: <BLU0-SMTP271BB6ABBA3B0E42240E898E2360@phx.gbl>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_DEF57581-7C77-44AB-B2CA-336AFCA7EC86"
MIME-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
In-Reply-To: <CAMyk_AZ2uawzHxZqOQUeUf2C98JeEDGmTZh8St+Csc-_yBfwuA@mail.gmail.com>
Date: Sat, 31 Aug 2013 02:07:30 +0200
CC: Developers Mailing List PHP <internals@lists.php.net>
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> <BLU0-SMTP4110E87ADD325FE1C6300D7E2350@phx.gbl> <CAMyk_AZ2uawzHxZqOQUeUf2C98JeEDGmTZh8St+Csc-_yBfwuA@mail.gmail.com>
To: Lazare Inepologlou <linepogl@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Argument unpacking
From: bobwei9@hotmail.com (Bob Weinand)

--Apple-Mail=_DEF57581-7C77-44AB-B2CA-336AFCA7EC86
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"

Hi!

Am 31.8.2013 um 01:39 schrieb Lazare Inepologlou <linepogl@gmail.com>:

>=20
>=20
> 2013/8/31 Bob Weinand <bobwei9@hotmail.com>
> Hi!
>=20
> Am 31.8.2013 um 00:27 schrieb Lazare Inepologlou <linepogl@gmail.com>:
>=20
> > 2013/8/30 Stas Malyshev <smalyshev@sugarcrm.com>
> >
> >>> 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 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.
> >>
> >>
> > 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.
>=20
> 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.
>=20
>=20
>=20
> Please read carefully my argument. The alternative is to actually call =
the function normally with the arguments expanded in the code.=20
>=20
> In other words, the alternative to this:
> strpos( ...$array , 3 );  // which cannot be verified statically
>=20
> is this:
> strpos( $array[0] , $array[1] , 3 ); // which is perfectly verifiable.
>=20
>=20
> The power of this proposal is found when used with optional arguments =
(or variadic arguments) which always come last anyway.
> =20
>=20
> Lazare INEPOLOGLOU
> Ing=E9nieur Logiciel

This also isn't anything it ever would write, because it just doesn't =
make any sense for two or three arguments.

In my opinion you only should unpack arrays when it's at the end =85 AND =
when you can verify how many parameters will be inserted. Just shorter. =
Because writing:

func($array[0], $array[1], $array[2], $array[3], $array[4], $array[5], =
$array[6], "value");

is just ugly to write and to read.

if (count($array) =3D=3D 7)
    func(...$array, "value");

is much more readable, I think.

Bob Weinand=

--Apple-Mail=_DEF57581-7C77-44AB-B2CA-336AFCA7EC86--