Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68768
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <BLU0-SMTP4110E87ADD325FE1C6300D7E2350@phx.gbl>
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>
Date: Sat, 31 Aug 2013 01:39:48 +0200
Message-ID: <CAMyk_AZ2uawzHxZqOQUeUf2C98JeEDGmTZh8St+Csc-_yBfwuA@mail.gmail.com>
To: Bob Weinand <bobwei9@hotmail.com>
Cc: Malyshev Stas <smalyshev@sugarcrm.com>, 
	Developers List PHP Mailing <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8ff1cefe2f987804e532bea4
Subject: Re: [PHP-DEV] [RFC] Argument unpacking
From: linepogl@gmail.com (Lazare Inepologlou)

--e89a8ff1cefe2f987804e532bea4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2013/8/31 Bob Weinand <bobwei9@hotmail.com>

> Hi!
>
> Am 31.8.2013 um 00:27 schrieb Lazare Inepologlou <linepogl@gmail.com>:
>
> > 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 t=
he
> >> cost of making it overall more complex and hard to understand. I can s=
ee
> >> 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 ide=
a
> >> what's going on at all and what is sent where.
> >>
> >>
> > I agree with Stas here. If an argument comes after an unpacked array, i=
ts
> > 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_arra=
y
> with some array_merge, which makes it as difficult for static analysis as
> the
> new syntax does. This really is a non-argument.
>
>

Please read carefully my argument. The alternative is to actually call the
function normally with the arguments expanded in the code.

In other words, the alternative to this:
strpos( ...$array , 3 );  // which cannot be verified statically

is this:
strpos( $array[0] , $array[1] , 3 ); // which is perfectly verifiable.


The power of this proposal is found when used with optional arguments (or
variadic arguments) which always come last anyway.


Lazare INEPOLOGLOU
Ing=C3=A9nieur Logiciel




> 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.
> >
> > I suggest that argument unpacking should be limited to the last argumen=
ts
> > 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=C3=A9nieur Logiciel
> >
> >
> >
> > --
> >> 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 o=
f
> 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
> }
>
> variadic(...$array1, ...$array2);
>
>
> Bob Weinand
>
>

--e89a8ff1cefe2f987804e532bea4--