Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111079
MIME-Version: 1.0
References: <CAF+90c_DPYqzOH1TU2mrG7cjh87RNXEzMx3hAAeDRfbTPpGVvw@mail.gmail.com>
In-Reply-To: <CAF+90c_DPYqzOH1TU2mrG7cjh87RNXEzMx3hAAeDRfbTPpGVvw@mail.gmail.com>
Date: Mon, 20 Jul 2020 17:57:01 +0100
Message-ID: <CALKiJKqbr-AivZUxTXbW_zQWr4kx9BinOs6q6ARXmad0AFA49g@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000eba87c05aae2651b"
Subject: Re: [PHP-DEV] [VOTE] Named arguments
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000eba87c05aae2651b
Content-Type: text/plain; charset="UTF-8"

On Fri, 10 Jul 2020 at 09:42, Nikita Popov <nikita.ppv@gmail.com> wrote:

> Hi internals,
>
> I have opened voting on the named arguments RFC:
> https://wiki.php.net/rfc/named_params
>



I see this vote is currently running close to the super-majority threshold.

To those of you whose main concern is the need for libraries to consider
backwards compatibility of parameter names, I wanted to point to Symfony's
"compatibility promise" [1] and in particular the general disclaimer on
anything marked "@internal". There will always be ways to use a library
which the author didn't intend; it would be quite reasonable for a library
author to say "I do not promise that calling these methods with named
parameters will not break".

[1] https://symfony.com/doc/current/contributing/code/bc.html

To those of you who feel there are better ways to design APIs to avoid ever
needing to skip parameters, it would be great to see some ideas to make
those alternatives easier. For instance, if you think parameter objects
plus the builder pattern is the right way to go, how can we reduce the
boilerplate currently required to define the builder class?

Regards,
-- 
Rowan Tommins
[IMSoP]

--000000000000eba87c05aae2651b--