Re: [RFC] Named arguments

> 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