Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71102
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.215.177 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
In-Reply-To: <52D301F3.9010600@gmail.com>
Date: Sun, 12 Jan 2014 22:07:46 +0100
Cc: Andrea Faulds <ajf@ajf.me>,
 internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <A6064D48-E61A-42C4-9A3F-67596D7B0F9E@googlemail.com>
References: <581A185E-0F00-4B49-AA87-859D75E63BA2@googlemail.com> <CAJ26g5Q40RH9c80r0=7wQNoBnciNi-=n_VdAaDMfqbqbwKfpJw@mail.gmail.com> <52D2ED5F.4000706@gmail.com> <52D2EE69.9070806@ajf.me> <52D301F3.9010600@gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] Revisiting the "Named Arguments" RFC
From: ingwie2000@googlemail.com (Kevin Ingwersen)

The parser would have to be taught an actual, pretty simple, condition: =
Perform unusual parsing between parantheses. In pseudo code, that=92d =
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 =84think different=93, then I doubt that =
it=92ll 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:
>>=20
>> This is why I proposed earlier that we should make =3D> in function =
calls work identically to array syntax, such that { const bar =3D =
"foobar"; foo(bar =3D> 3); } would be the same as foo("bar" =3D> 3);
>>=20
>> 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" =3D> 7]
>>=20
>> It would allow a shorter form while avoiding inconsistency with array =
syntax.=20
>=20
> The question, is, is the parser robust enough to guarantee that the =
following will all be parsed correctly:
>=20
> do_soap_call(namespace: 'foo');
> check(if: $arriving =3D=3D=3D true, true: 'Hello', false: 'Goodbye');
> $callback =3D array( function: function() { }, array: array( ) );
>=20
> 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?)
>=20
> 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' =3D> 3], but not the =
same as [bar =3D> 3], except when it is, because of "undefined constant, =
assumed string" fallbacks...?
>=20
> 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 =3D> 3);" =
would mean "call function foo(), with argument $bar set to 3".
>=20
> Regards,