Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71078
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain bof.de designates 80.242.145.70 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <581A185E-0F00-4B49-AA87-859D75E63BA2@googlemail.com>
References: <581A185E-0F00-4B49-AA87-859D75E63BA2@googlemail.com>
Date: Sun, 12 Jan 2014 09:16:13 +0100
Message-ID: <CAJ26g5Q40RH9c80r0=7wQNoBnciNi-=n_VdAaDMfqbqbwKfpJw@mail.gmail.com>
To: nikic@php.net
Cc: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b6dc0bc966dae04efc19259
Subject: Re: [PHP-DEV] Revisiting the "Named Arguments" RFC
From: bof@bof.de (Patrick Schaaf)

--047d7b6dc0bc966dae04efc19259
Content-Type: text/plain; charset=ISO-8859-1

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 :)

I'd like to offer my thoughts on the open questions in the RFC:

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 :)

One question, given that syntax: would
$foo = 'bar';
test($foo => 123);
pass a named parameter named 'bar' ? That would be my visual expectation,
and is what feels wrong about the alternate proposals.

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.

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.

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.

best regards
  Patrick

--047d7b6dc0bc966dae04efc19259--