Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71079
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.215.174 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
In-Reply-To: <CAJ26g5Q40RH9c80r0=7wQNoBnciNi-=n_VdAaDMfqbqbwKfpJw@mail.gmail.com>
Date: Sun, 12 Jan 2014 10:14:41 +0100
Cc: nikic@php.net,
 internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <EE1EFE9A-AF95-4301-85E2-FE6A6920FA12@googlemail.com>
References: <581A185E-0F00-4B49-AA87-859D75E63BA2@googlemail.com> <CAJ26g5Q40RH9c80r0=7wQNoBnciNi-=n_VdAaDMfqbqbwKfpJw@mail.gmail.com>
To: Patrick Schaaf <bof@bof.de>
Subject: Re: [PHP-DEV] Revisiting the "Named Arguments" RFC
From: ingwie2000@googlemail.com (Kevin Ingwersen)

Am So. Jan. 12 2014 09:16:13 schrieb Patrick Schaaf:

> First of all, I'd love seeing this feature in PHP, and it would be a =
very
> large incentive to upgrade to 5.6 asap when it would be included =
(without
> bugs of course :)
>=20
Not just you! :)

> I'd like to offer my thoughts on the open questions in the RFC:
>=20
> Regarding Syntax at the call site, I feel that it is exactly right the =
way
> it is proposed / implemented now. That way mirrors most closely the =
syntax
> of static array definition, while saving some typing (omitting of =
double
> quotes) where key names do not clash with keywords. In fact, once
> established, I would love static array initialization to also permit
> nonclashing keys to omit the doublequotes :)
>=20
> One question, given that syntax: would
> $foo =3D 'bar';
> test($foo =3D> 123);
> pass a named parameter named 'bar' ? That would be my visual =
expectation,
> and is what feels wrong about the alternate proposals.
I wondered that too, and I think that is what the engine will do by its =
own; resolving the variable into its value. Hence, this option won=92t =
be possible; but that=92s ok iMO as it=92s pretty logical.

> Regarding the separation of positional and named stuff when
> packing/unpacking (the python *kw vs. **kw distinction) I feel that =
would
> be unnatural. There is no syntactic precedent in PHP regarding =
notation,
> and I think where desired, explicit code using array functions should
> always easily be able to make the split in an obvious fashion.
>=20
> Regarding signature violation, and clearly just as a personal opinion, =
I
> don't see LSP as a law of languages, but just as a good coding =
practise.
> Thus, I would be happy to just have the same runtime checks in place =
for
> ordinary functions, against the actual method called, with exactly the =
same
> error behaviour as for ordinary function calls, instead of an =
additional
> set of errors and/or warning coming from structural checking of child =
and
> parent methods. I think that's what the RFC / current implementation =
does,
> but the RFC seems unclear in that regard.
+1 - agreed. We already have warnings and exceptions for things such as =
BadFunctionCall etc. Why not just utilize these instead? That would just =
save some work! :)

> Finally, regarding internal functions and their arginfo and the naming =
of
> parameters there... in my imagination, that is the think that would =
still
> need the most work, and would tend to bikeshedding regading the =
parameter
> names set in stone in the process... Which leads me to the question =
whether
> that work wouldn't be best postponed:
> - create variations of the arginfo declarations that explicitly say, =
on a
> function-by-function basis, whether named parameters should be =
supported
> - forbid use of named parameters with any function not yet modified =
and
> reviewed in that fashion
> Personally, being able to use named parameters in our own userland
> functions and classes, is much more important than use against =
internal
> functions, and postponing the feature altogether due to the internal
> functions not being fit to accept named parameters, would be sad.
Yeah, I agree. As plain C does not have =84real arrays=93 such as C++ =
may offer, it would be ultra hard to code it in. I mean, it is already =
quite uneasy to use scripted arrays within native functions=85or =
Objects. Hence, I wouldn=92t really offer named arguments in that case, =
as one=92d have to create a whole new argument parser and extractor, =
which would mean even more changes on the actual engine to offer the =
userland abilities to the =84devland=93.
I agree to not change the C side too much from that point of view.

Another thought i had was concerning the =3D> operator. It currently =
is,as far as I know, used in two things: foreach and arrays. But another =
suggestion on the page was mentioning a colon:

	test(word1:=93Hello=93, word2:=93Bar=93);

Colons are currently only used, afaik, in =84shorthand=93 if-else =
statements:

	$var =3D (isset($argv[2]) ? $argv[2] : null);

And, in another token, its used for static calling:

	Fubar::meep();

So therefore, I would actually suggest using colons. It does quite mimic =
the ObjC calling style, but it keeps the old-fashioned function style, =
which I honestly prefer (besides, adopting an ObjC messaging style =
syntax would be either ultra-hard or never accepted :D).

Kind regards, Ingwie=