Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68793
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.160.41 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CADajX4CxKrNTmMSnXRrwsYS2FrFi2evAVEyO2ZZZ0JB22uW-Rg@mail.gmail.com>
References: <CAF+90c_Ld1BAaj2kd+hhdNkcbj6Mar2EZSYPJaSFWqmV_tb=Xw@mail.gmail.com>
	<CADajX4CxKrNTmMSnXRrwsYS2FrFi2evAVEyO2ZZZ0JB22uW-Rg@mail.gmail.com>
Date: Sat, 31 Aug 2013 14:37:56 -0700
Message-ID: <CAESVnVou1TL0xcn04qzkuoasdgJgp1LiwXUo6E3QtsdvktsvpQ@mail.gmail.com>
To: Adam Harvey <aharvey@php.net>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8ff1c35001ff0304e54527ca
Subject: Re: [PHP-DEV] [RFC] Argument unpacking
From: pollita@php.net (Sara Golemon)

--e89a8ff1c35001ff0304e54527ca
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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 <aharvey@php.net> wrote:

> On 30 August 2013 08:23, Nikita Popov <nikita.ppv@gmail.com> 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, since it's at least not worlds away from C++ (and there
> are other precedents for it, as you noted), but it looks really weird
> to me as the splat operator. It looks like you're hesitant to call the
> function or ashamed of $params rather than unpacking something.
>
> I know there's a symbol soup issue for by-ref variadic arguments, as
> you mentioned in the RFC, but I think that's an unusual enough use
> case that * is still the better option =97 it doesn't break the flow of
> the code as much as a three character operator, and while it's no more
> visually intuitive than ..., it does have the advantage of being what
> Python and Ruby used.
>
> I'm raising this in this thread because I'm more concerned about the
> visual impact of it here, but obviously whatever we use as the
> operator for one is what we should use for the other, assuming both
> RFCs are accepted.
>
> Adam, who is wincing as he sends this at the likely subthread that will
> ensue.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--e89a8ff1c35001ff0304e54527ca--