Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68950
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <522AFA6A.8010501@mjburgess.co.uk>
References: <CAF+90c85v_VTPTPanBcTJ70Ff6pm6fRgAGs4n1uoaA+B9UZg=w@mail.gmail.com>
	<CAN=kQJfAavn2sjPHje1TW6Y_0xAeAqVgho-MvPHQkk2erDgSpA@mail.gmail.com>
	<522AFA6A.8010501@mjburgess.co.uk>
Date: Sat, 7 Sep 2013 11:55:16 -0500
Message-ID: <CAN=kQJeJjo0sekHoLqyXjL1o7HbzWFUPPY=oc5v0QhJkt8FKQQ@mail.gmail.com>
To: Michael John Burgess <michael@mjburgess.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [RFC] Named parameters
From: leverton@gmail.com (Matthew Leverton)

On Sat, Sep 7, 2013 at 5:05 AM, Michael John Burgess
<michael@mjburgess.co.uk> wrote:
> The position of parameters and the name of the function must already be
> maintained... I dont see why appropriately naming variables is such a
> burden.
>
I wouldn't necessarily make this objection if this were a day-1
feature. But it does bother me somewhat that all of a sudden code
retro-actively starts supporting named parameters.

The OCD in me shudders to think about now having to parse through
people's code like:

substr('length' => 1, 'string' => 'Hello World');

Now I see the function, and I have to see how they ordered their
parameters. Why was 'start' omitted... is this a warning due to using
NULL as an int.. did the person mean 'start', etc? It's just one
example, but I know that this sort of code will start cropping up
everywhere. So that's why I call this a nuisance. It just seems like a
very marginal gain for lots of potential headaches.

But I don't mean to make a mountain out of a molehill. After giving it
some thought, I'd like some consideration to be given to providing an
explicit syntax in the RFC at least so people consider all
alternatives.

I just don't think that giving people the ability to call a function
with two well ordered parameters by using named parameters is worth
causing all future code to diverge into two drastically different
calling styles.

My strong preference would be a syntax that separates the two types of
parameters, such as the following:

function func($a, $b, ...$params, [$c = 'foo', $d = 'bar'])
{

}

func($a, $b, $extra, 'd' => 'override');

Here $a and $b are not named parameters and must be present. Extra
positional parameters are sent to $params. The parameters enclosed in
square brackets must be passed in by name as the last parameters, but
can be omitted.

I don't like the $ on the named parameter when calling because it
implies that this works:

$d = 'c';
func($a, $b, $extra, $d => 'override');

Now is 'c' overridden or 'd'?

So I'll give this issue a rest unless somebody wants to further
discuss what the concrete syntax might look like.

--
Matthew Leverton