Hi!
Am 31.8.2013 um 00:27 schrieb Lazare Inepologlou <linep...@gmail.com>:
> 2013/8/30 Stas Malyshev <smalys...@sugarcrm.com>
>
>>> don't see a reason why one should explicitly disallow doing multiple
>>> unpacks.
>>
>> Because it makes very hard to understand what's going on and makes no
>> sense semantically.
>>
>>> As you can see, here two arguments are unpacked in one call.
>>
>> 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 agree with Stas here. If an argument comes after an unpacked array, its
> position is not certain until runtime. This makes life difficult for static
> analysis tools, which is one of the reasons for introducing the new syntax.
The alternative is for users to use what we have now: call_user_func_array
with some array_merge, which makes it as difficult for static analysis as the
new syntax does. This really is a non-argument.
And should we really restrict the user's code with some arbitrary limits?
It just makes the user use some really ugly hacks nobody wants to see.
> Even in the use case of Nikita, the two arguments to be unpacked come
> without any standard arguments between or after them.
>
> I suggest that argument unpacking should be limited to the last arguments
> only.
An example where it really would make sense is:
function long ($arg, $arg2, $arg3, $arg4, $arg5, $arg6, $arg7, $string) {
// do something with your arguments
}
// just instead of copying the seven parameters; increases readability
// and don't argue this would be badly statically analyzable - it is, but this
isn't
// the point. I want to show that people may find here some use case.
function short (...$args) {
if (count($args))
return long(...$args, "some value");
}
> Lazare Inepologlou
> Ingénieur Logiciel
>
>
>
> --
>> Stanislav Malyshev, Software Architect
>> SugarCRM: http://www.sugarcrm.com/
>> (408)454-6900 ext. 227
I finally am in favor of the proposal, because it allows removing a lot of ugly
call_user_func_array calls which aren't really well readable. (and naturally
because it allows passing the variadic parameters if that rfc will be accepted)
And I think you are really arguing about non-issues.
Example: Multiple uses of unpacking syntax makes sense when you call a
function with a variadic parameter:
function variadic (...$args) {
// do something
}
variadic(...$array1, ...$array2);
Bob Weinand
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
