Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110015
Date: Tue, 5 May 2020 19:27:59 +0200 (CEST)
Reply-To: Thomas Bley <mails@thomasbley.de>
To: Marco Pivetta <ocramius@gmail.com>, Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Message-ID: <770955649.245407.1588699679171@email.ionos.de>
In-Reply-To: <CADyq6s+pfDfDey8hGT=zDD5hwyKjq3q6V8xPVyP03z=6MwGgdQ@mail.gmail.com>
References: <CAF+90c8m-CB3ZxAHeoOJVxJGhysLfZqpz3mq475GPnMEDA6iqQ@mail.gmail.com>
 <CADyq6s+pfDfDey8hGT=zDD5hwyKjq3q6V8xPVyP03z=6MwGgdQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Importance: Normal
Subject: Re: [PHP-DEV] [RFC] Named arguments
From: mails@thomasbley.de (Thomas Bley)

> Marco Pivetta <ocramius@gmail.com> hat am 5. Mai 2020 um 16:11 geschrieben:
> 
> Hey Nikita,
> On Tue, May 5, 2020 at 3:51 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
> > Hi internals,> I've recently started a thread on resurrecting the named arguments proposal(https://externals.io/message/109549), as this has come up tangentially insome recent discussions around attributes and around object ergonomics.> I've now updated the old proposal on this topic, and moved it back underdiscussion: https://wiki.php.net/rfc/named_params> Relative to the last time I've proposed this around PHP 5.6 times, I thinkwe're technically in a much better spot now when it comes to the supportfor internal functions, thanks to the stubs work.> I think the recent acceptance of the attributes proposal also makes this agood time to bring it up again, as phpdoc annotations have historically hadsupport for named arguments, and this will make migration to thelanguage-provided attributes smoother.
> As mentioned some days ago, I see named parameters as an added liability,rather than values.The rationale of my negativity around the topic being that a diff likefollowing is now to be considered a BC break:
> ```diff-function foo($parameterName) { /* ... */ }+function foo($newParameterName) { /* ... */ }```
> In addition to that, the feature seems to be especially designed to workwith particularly bad API (anything with a gazillion optional parameters,such as all the OpenSSL nightmares in php-src).In practice, the issues around bad API (in this case, bad = lots ofoptional parameters, maybe even ordered arbitrarily) are fixed by usingproper value types and structs or value objects:
> ```phpmyHorribleLegacyAndOrganicallyGrownApi(
> ...MyInfiniteSequenceOfParametersAsProperValidatedStructure::fromArray($stuff)->toSequentialParameters());```
> For the few use-cases where this is needed, the userland solution seems tobe sufficient, without introducing catastrophic BC boundary expansions.
> Unless I'm not seeing an incredible (hidden, to me) value from thisfunctionality, this is a clear -1 from me.
> Marco Pivetta
> http://twitter.com/Ocramius
> 
> http://ocramius.github.com/

Hi,

I think it's a valid point that changing parameter names can be a BC break. In case the type declaration or the semantic of the parameter changes, it's good to let the code break.

I guess that tools for static code analysis will be able to detect parameter name changes?

Regards
Thomas