Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68923
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c85v_VTPTPanBcTJ70Ff6pm6fRgAGs4n1uoaA+B9UZg=w@mail.gmail.com>
References: <CAF+90c85v_VTPTPanBcTJ70Ff6pm6fRgAGs4n1uoaA+B9UZg=w@mail.gmail.com>
Date: Fri, 6 Sep 2013 14:58:15 -0500
Message-ID: <CAN=kQJfAavn2sjPHje1TW6Y_0xAeAqVgho-MvPHQkk2erDgSpA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
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 Fri, Sep 6, 2013 at 11:39 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> The RFC and implementation are not yet complete. I mainly want to have
> feedback on the idea in general and on the Open Questions (
> https://wiki.php.net/rfc/named_params#open_questions) in particular.
>
I feel like this will just encourage more core PHP functions with an
unmanageable number of parameters. Will there be any proposed
guidelines to how future functions will make use of named parameters?
e.g., Will we see native functions with 20 arguments?

What I don't like about named parameters is that if I build a library,
now even my parameter names are unchangeable if I don't want to break
any backward compatibility, since I never know if somebody will decide
to call my single parameter method with named parameters. Are we
prepared to go through every PHP function and make sure the names of
the parameters are set in stone before this feature would go live?

So I'm neutral to this proposal, as I would never purposefully build a
function that is so convoluted that it needs named parameters, but I
understand that's how some people like to write code, and it could be
useful in extreme cases.

--
Matthew Leverton