Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68780
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain adamharvey.name designates 209.85.223.178 as permitted sender)
MIME-Version: 1.0
Sender: adam@adamharvey.name
In-Reply-To: <CAF+90c9bQY31ynfXn=jsEFbJX_eKObuS+xahuopJQ1h0Ra2Qeg@mail.gmail.com>
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> <CAF+90c9bQY31ynfXn=jsEFbJX_eKObuS+xahuopJQ1h0Ra2Qeg@mail.gmail.com>
Date: Sat, 31 Aug 2013 10:49:29 -0700
Message-ID: <CADajX4CLC1KvZPWP_hufyZoUWwUzLf6T9Oh88cGkHHLVjjYi_A@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Argument unpacking
From: aharvey@php.net (Adam Harvey)

On 31 August 2013 03:21, Nikita Popov <nikita.ppv@gmail.com> 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 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 can grok this, but I'd rather not have to work through it when
reading someone else's code. The likely code in current versions of
PHP using call_user_func_array() would almost certainly be clearer
here. So I think I'd prefer to disallow multiple splats in a function
invocation too.

<snip>
> Of course, maybe my logic is flawed because I give too much credit to
> programmers and assume that they will employ features when reasonable and
> not when "hey, why don't I go put a ... in here!"

At the risk of sounding even more bitter than normal, you need to
spend more time in ##php with that attitude. ;)

> Anyway, I don't think having a trailing fixed argument is *that* absurd. =
A
> pretty pointless example off the top of my head would be
> $this->query($query . ' LIMIT ?', ...$params, $limit), i.e. just adding
> another bound param to a set of existing ones.
>
> I don't really insist on allowing the trailing normal args, because I don=
't
> think they would be useful particularly often, but I just fail to see wha=
t
> we gain by forbidding them.

I have pretty much the same readability concern as with multiple
splats =E2=80=94 this example is clear, but I'm not sure it's so clear with=
 a
larger, more verbose set of arguments. This seems to require a
slightly sharper eye to me (OK, it'd be better in a fixed width
editor, admittedly):

do_something($a_long_variable, $another_long_variable,
...$hey_a_splat, $something_else, $foo, $bar)

I care less about this than multiple splats, but it's still a concern to me=
.

Adam, who will send another e-mail momentarily to paint some bikesheds.