> Marco Pivetta <ocram...@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....@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
