On 05/11/2014 10:24, Chris Wright wrote:
On 4 November 2014 18:14, Rowan Collins <rowan.coll...@gmail.com
<mailto:rowan.coll...@gmail.com>> wrote:
On 3 November 2014 22:45:11 GMT, Chris Wright <daveran...@php.net
<mailto:daveran...@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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
