2013/8/31 Bob Weinand <bobw...@hotmail.com>
> 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.
>
>
Please read carefully my argument. The alternative is to actually call the
function normally with the arguments expanded in the code.
In other words, the alternative to this:
strpos( ...$array , 3 ); // which cannot be verified statically
is this:
strpos( $array[0] , $array[1] , 3 ); // which is perfectly verifiable.
The power of this proposal is found when used with optional arguments (or
variadic arguments) which always come last anyway.
Lazare INEPOLOGLOU
Ingénieur Logiciel
> 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
>
>
