Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68937
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAN=kQJe32_uY2Wcau9A0jz2_N1jmOntmSCHdW8LYdOicSegiJw@mail.gmail.com>
References: <CAF+90c85v_VTPTPanBcTJ70Ff6pm6fRgAGs4n1uoaA+B9UZg=w@mail.gmail.com>
	<CAN=kQJfAavn2sjPHje1TW6Y_0xAeAqVgho-MvPHQkk2erDgSpA@mail.gmail.com>
	<522A87EB.7080702@rotorised.com>
	<CAN=kQJe32_uY2Wcau9A0jz2_N1jmOntmSCHdW8LYdOicSegiJw@mail.gmail.com>
Date: Sat, 7 Sep 2013 09:37:58 +0200
Message-ID: <CAJWj5+Fjz+YCQOjfbOe6fX0U+hUhMJGZMvn5pS9KBhVBB0OffA@mail.gmail.com>
To: Matthew Leverton <leverton@gmail.com>
Cc: Ryan McCue <lists@rotorised.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Named parameters
From: simonsimcity@gmail.com (Simon Schick)

On Sat, Sep 7, 2013 at 5:29 AM, Matthew Leverton <leverton@gmail.com> wrote:
>
> The big difference here is if I accept an options array, I understand
> that the keys are important and would never break backward
> compatibility by changing a parameter name. This isn't a case of "if
> you don't like it, then don't use it" because every function I create
> now has to respect the possibility of accepting named parameters,
> whether I care about it or not. And I sure hope every function I call
> is created by and maintained by somebody with those same
> sensibilities.
>
> My opinion is that this really isn't as cool as it sounds, especially
> since we have short array syntax. Again, I don't really care if it's
> accepted into PHP, but I think it will be more of a minor nuisance for
> me than anything else.
>
> --
> Matthew Leverton
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Hi, all

Would it be an option, to change the way named functions are declared?
This way you would mark a function explicitly as having named
parameters.
 This increases the learning-curve for PHP, but for me, it seems a
valid approach ...

An example that comes to my mind, is to call this a "named" function
... Feel free to add a better keyword.
This would then look something like this:


named function functionHavingNamedParamsEnabled($firstParam, $secondParam) {}
function functionHavingNamedParamsDisabled($firstParam, $secondParam) {}

functionHavingNamedParamsEnabled( "secondParam" => "secondValue",
"firstParam" => "firstValue");
// Will work ...

functionHavingNamedParamsDisabled( "secondParam" => "secondValue",
"firstParam" => "firstValue");
// Will not work, because this function is not declared to support named params.


Just an idea for a compromise ..
What I don't like here would be if I'd have to add some cryptographic
char instead of a keyword to the definition of the function.

I, too, am quite neutral to this feature.

Bye,
Simon