Recent searches
Search options
Administered by:
"Using positional arguments requires less code today, but you pay for this decrease in volume of code with an increase in the risk that changes will cascade into dependents later." (Sandi Metz)
@monospace Ever heard of our lord and saviour, Semantic Versioning?
@chrastecky I don't see your point.
@monospace Using positional arguments doesn't matter if your dependencies use semantic versioning, there will be no BC break until a new major version (and you should handle major version upgrades with care anyway).
Not that I think named arguments are bad, I myself use them (and design libraries with them) very often, just pointing out that semver solves it pretty well.
@chrastecky I see. You're right, that just wasn't the point. In this quote, Sandi is highlighting the fact that changes to the arguments signature of a method will have much more substantial consequences when they're positional than when they're named.
For example, if you already have a positional array/hash argument, it needs to be _and stay_ the last one. Adding a new argument, even if it has a default value, will force you to change all calls of that method. Not so with named arguments.
@chrastecky @monospace that’s a library consumer perspective not a system designer/developer one. You do no semver nor package each of your own classes (?)
@alessandrofazzi @monospace If you control both the providing and consuming part of the code, it's not that huge of an issue, you simply edit both sides, usually with the help of some tool, like your IDE.