The parser would have to be taught an actual, pretty simple, condition: Perform unusual parsing
between parantheses. In pseudo code, that’d be:
if(in function argument list)
if(has named parameters)
obtain, assign and pass the paraneters.
else
fall back to traditional positioned parameters.
It would also have to ignore keywords. But that means that it would have to temporarily swap
T_CONSTANTS for anything that is left from the colon. OR the colon must be attached to the last
character. I.e.:
copy(from: $file, to: $file); // valid.
copy(from : $file, to : $file); // may thro an error for undefined constant?
So if the parser knows when to „think different“, then I doubt that it’ll be showing off
un-robustness. However, what if the closing paranthese is missing? That are things that concern me
now - actual syntax errors.
Am So. Jan. 12 2014 21:58:27 schrieb Rowan Collins:
> On 12/01/2014 19:35, Andrea Faulds wrote:
>>
>> This is why I proposed earlier that we should make => in function calls work identically
>> to array syntax, such that { const bar = "foobar"; foo(bar => 3); } would be the same
>> as foo("bar" => 3);
>>
>> However, strings are quite inconvenient. So I suggest a new, bareword-only syntax, namely
>> the colon. foo(bar: 3); would never mean the constant, and only mean the parameter named bar. We
>> could then add this syntax to array declarations: [bar: 3, "foo" => 7]
>>
>> It would allow a shorter form while avoiding inconsistency with array syntax.
>
> The question, is, is the parser robust enough to guarantee that the following will all be
> parsed correctly:
>
> do_soap_call(namespace: 'foo');
> check(if: $arriving === true, true: 'Hello', false: 'Goodbye');
> $callback = array( function: function() { }, array: array( ) );
>
> I can't think of a case off the top of my head where it would be *theoretically*
> impossible, but that doesn't mean it would be trivial to implement, and if there were any cases
> where it couldn't be used, I'd personally much rather it didn't exist at all. (And
> what about secondary parsers, e.g. syntax highlighters?)
>
> I'm also not convinced that it's something worth having more than one way to write,
> as it just makes code harder to read for new coders: will it be obvious that [bar: 3] is the same as
> ['bar' => 3], but not the same as [bar => 3], except when it is, because of
> "undefined constant, assumed string" fallbacks...?
>
> I think I'd personally lean towards using a $ to mark named parameters, and simply not
> allow dynamically choosing which parameter gets passed (that strays close to "variable
> variable" territory anyway, of which I'm not a fan). If I think of the function signature
> "function foo($bar) { ... }", I would tend to think of the argument as "$foo"
> not "foo" anyway, so it doesn't seem a stretch that "foo($bar => 3);"
> would mean "call function foo(), with argument $bar set to 3".
>
> Regards,