On 23/09/2013 21:19, Nikita Popov wrote:
That's a general issue that's not really related to multiple unpacks. It
could just as well happen without any unpacks at all ( f(a => 'a', a =>
'b') ) or when unpacking an iterator (which is allowed to have duplicate
keys).
Fair enough. However, I'm a little concerned about the other named
parameters issue here. f(1, ...$args1, 2, ...$args2) would be quite
straightforward with numerical arguments, but with multiple unpacks
which can also unpack named parameters, I am worried things could get
quite confusing. Then again, it would be perfectly possible to write
awful code with array_merge etc. anyway, so I can't really object to it.
The variadics RFC does not allow defining such functions, correct. But
it's a fact that our standard library already makes use of this pattern
(variadic arguments first and a fixed one at the end), so it seems
somewhat reasonable to support them too.
Why would it make the code clearer? Using the array_uintersect example:
// unpack with trailing arg
array_uintersect(...$arrays, $compare);
// array_merge
array_uintersect(...array_merge($arrays, array($compare)));
Maybe I'm alone here, but I find the first line clearer than the second.
Actually, I'm changing my mind here. I can see the utility here dealing
with existing functions. The inconsistency with the definition is still
a bit irritating, since you can call such functions easily but the
definitions would be as easy since you'd have to chop up the ...$args in
the definition, but all may be sacrificed in the name of
backwards-compatibility. :P
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
