I as well can come up with lots of examples that aren't a good fit for named parameters.
#Php 8 named arguments code#
It would encourage people to write large method definitions, which in turn often indicates a code smell. # As a programmer doing client workĪnother argument is that this RFC would encourage bad API design.
#Php 8 named arguments Patch#
This means that argument names might change in minor and patch releases.ĭon't deny all PHP developers this flexibility, because you're afraid of a slight chance it might break something somewhere in the far far future. Just put this in the README: **Heads up**: this package doesn't actively support named arguments. Now even if you, as an open source maintainer, don't want to take the responsibility of making sure argument names don't change between major releases, here's what you do: tell your users you won't actively support named arguments, and using them is at their own risk. We either add or remove arguments, but I'd say we never had to change names.Īctually that's an interesting thought: argument lists already are prone to breaking backwards compatibility: changing the order of arguments already is a breaking change! And we're dealing with that just fine now, aren't we? I've been working at Laravel for 4 years now and I rarely find us wanting to change argument names in a refactor. Oh and here's Mohamed Said, one of the core maintainers of Laravel: I'm not the only one with that opinion by the way, Nicolas Grekas is amongst the people voting yes, and he knows a thing or two about OSS development. On Twitter or subscribe to my newsletter: If you want to stay up to date about what's happening on this blog, you can follow me Noticed a tpyo? You can submit a PR to fix it. And the only reason we decided to do renames on those occurrences, was because we were already working on a new major version and we figured we might as well improve the naming a little bit while we were at it. Now, let me tell you something from my point of view as an open source maintainer: this rarely happens.Īs a matter of fact, I can only think of a handful occurrences.
If, for some reason, the open source maintainer would want to change the name of the $collection or $disk variables, they would have to tag a major release, because named arguments would make that a breaking change. > toMediaCollection( collection: 'downloads', disk: 's3') Named parameters would allow to call this function like so: $pendingMedia Imagine an open source package which has this function as part of its public API: public function toMediaCollection ( string $collection, string $disk = null)
#Php 8 named arguments software#
The main argument against named arguments - the PHP 8 puns continue - is that they would make maintaining open source software a pain: changing the name of an argument would become a breaking change. The number of arguments captured by prefixing ellipsis (.) can be zero or more.įunction sum (.Interface Default Methods # As an OSS maintainer $numbers-to capture all (remaining) arguments provided to that function into an array assigned to the named variable-in this case $numbers-that is accessible inside the function block.
When defining a function, if you need a dynamic number of variables provided to the function (i.e., you don't know how many arguments will be provided to that function when called in your code), prefix the ellipsis (.) token to a variable name-e.g. Both purposes apply to function arguments. There are TWO uses for the ellipsis (.) PHP token-think of them as packing an array and unpacking an array.
0 kommentar(er)
