Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78847
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.182 as permitted sender)
Message-ID: <545D0306.5040202@gmail.com>
Date: Fri, 07 Nov 2014 17:36:06 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "internals@lists.php.net" <internals@lists.php.net>
References: <CAGAGxbY+2G8zOWkHW7t_QhvFSFM=QLY7tSWJpGc8tAgpraLm-w@mail.gmail.com>	<E336496D-4FEB-4B99-ABA6-AFF0F42E5339@gmail.com> <CAGAGxbaFVSdtX6JbLPmX+Pg+oJ0mmNuHrrx3EM4q-XDV4JytZQ@mail.gmail.com>
In-Reply-To: <CAGAGxbaFVSdtX6JbLPmX+Pg+oJ0mmNuHrrx3EM4q-XDV4JytZQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Additional splat operator usage
From: rowan.collins@gmail.com (Rowan Collins)

On 05/11/2014 10:24, Chris Wright wrote:
>
> On 4 November 2014 18:14, Rowan Collins <rowan.collins@gmail.com 
> <mailto:rowan.collins@gmail.com>> wrote:
>
>     On 3 November 2014 22:45:11 GMT, Chris Wright <daverandom@php.net
>     <mailto:daverandom@php.net>> wrote:
>     >Good evening list,
>     >
>     >I'd like to open discussion a relatively simple and clear-cut RFC,
>     >either
>     >people will like it or they won't, there isn't a lot more to say here
>     >than
>     >what's in the RFC so please have a read.
>     >
>     >https://wiki.php.net/rfc/additional-splat-usage
>
>     I like the concept with list-style arrays, but find the behaviour
>     with regards associative arrays quite confusing. There's already a
>     difference in behaviour between array_merge and + in this regard,
>     and having a third way of writing the same thing isn't great - it
>     would apparently be legal to write $foobar = [...$foo, ...$bar];
>     to simply merge two existing arrays.
>
>
> It would be legal and I don't see this as a problem?
>
> This would be identical to array_merge($foo, $bar) and this is 
> intentional, the proposal is entirely intended to make merging literal 
> constant arrays and variable arrays simpler, it doesn't add yet 
> another set of rules for how the merge will be performed - we really 
> don't need that.

So, it's just an operator version of array_merge(), with no advantages 
other than brevity? I'm not sure why it's any more or less applicable to 
constant arrays vs variables than + or array_merge() are.

> More sensible uses w.r.t. associative array merging might be creating 
> the array to pass to PDOStatement->execute() (this is quite a 
> contrived example, but I have had effectively this use case in more 
> complex code):
>
> function execute_statement_with_extra_params(PDOStatement $stmt, array 
> $params)
> {
>     return $stmt->execute(['param1' => 1, 'param2' => 'value', 
> ...$params]);
> }

For this use case, since you're using associative arrays, the existing + 
operator works just fine:

$stmt->execute(['param1' => 1, 'param2' => 'value'] + $params);

Or perhaps, since + prefers the first of each set of duplicates, rather 
than the last, you might invert it to this:

$stmt->execute($params + ['param1' => 1, 'param2' => 'value']);

The inversion is a bit annoying sometimes, but the only real reason I 
can think of to use array_merge() (and therefore the proposed ... 
operator) is the special handling of numeric keys:

|[1, 2] + [3, 4] // evaluates to [1, 2]
array_merge([1, 2], [3, 4]); // |||evaluates to [1, 2, 3, 4]

|[...[1, 2], ...[3, 4]] // identical to array_merge() version


Since this "concatenation" behaviour is the main advantage of the new 
operator, it feels a little awkward for it to work with string keys at 
all. I would rather have a distinct concatenation operator:

[1, 2] . [3, 4] // evaluates to [1, 2, 3, 4]
['a' => 1] . ['a' => 2] // evaluates to [1, 2]

or if overloading . seems problematic, reuse ... as a binary operator:

[1, 2] ... [3, 4]
|
Then you'd have two operators for the two main behaviours: keep all 
keys, discard duplicates; and discard all keys, keep duplicates. The 
"smart" behaviour of array_merge() remains if you need it, but most of 
the time you should know whether you're dealing with associative or 
positional arrays, and can select the appropriate operator.

-- 
Rowan Collins
[IMSoP]