4 ms·
The assumption being that the language you are using does not have named parameters. Something all modern languages have, except, as usual, the ones the world i
by happytoexplain 2y ago
The assumption being that the language you are using does not have named parameters. Something all modern languages have, except, as usual, the ones the world is built on (JS, Java).
- bluefirebrand 2y agoNamed parameters are easy enough to mimic in JS using objects and the spread operation function foo({bar, baz}) { ... } foo({bar: 1, baz: false})
- ervine 2y agoLemme be an absolute pedant and say that's destructuring, not spreading. And correct me if I'm wrong, nothing worse than an incorrect pedant.
- asddubs 2y agothat's its own kind of horrible though. now either all your functions just take single object parameters or you have to remember which ones. and I get javascript is light on checking what was passed is actually what was expected but this seems to somehow make that situation even worse still
- lolinder 2y agoTypeScript is the answer.
- mewpmewp2 2y agoIs there anything wrong with taking a single parameter?
- wruza 2y agoNever had an issue with “remembering” part. At first I hated js/ts for its runtime and legacy quirks, but shortly after getting used to them it struck me that it’s a practical language with as little religion as possible. They just look at something and make it useful. Without thinking how much horrible it could be if they only imagined it. The ([…, ]{…}) approach is called “options object” which is a separate entity and is very convenient compared to e.g. python’s semi-infinite arguments lists.
- happytoexplain 2y agoI'm aware, but "mimic" is the key word here. Other languages are named-first. E.g. in Swift nobody is thinking "should I name this parameter?". They name it by default, because they have to choose an internal name anyway, and they only reach for the anonymous-parameter feature after explicitly considering "should I make this parameter anonymous?" In other words, this blog post is practically irrelevant to those languages.
- bertylicious 2y agoI don't agree. One can easily imagine how the "a bool for every edge case" approach won't scale for long when extending an existing code base. Regardless if the language or IDE makes you see the names of the booleans or not. I think the author's point is not so much about the names but about abstraction and concepts. Slapping another bool parameter onto a function and bifurcating its behavior with an `if` is easy to do, but hard to refactor once this has been done a couple times to that function.
- jandrese 2y agoThis is a fairly common pattern but it suffers from a big problem in that the compiler usually can't check your parameters for correctness. If you build a struct with the parameters but accidentally misname one that error is hard to catch. My ideal language would have function prototypes that look something like: return_type function_name(parameter_name type (default_value) [constraints], ...) If the default value is not set then the parameter must be passed or it is a compile error.
- nine_k 2y agoJS/TS has a pretty widespread convention for "named parameters": function foo({x, y, z=1}) { ... } It eschews positional parameters though, but makes passing aptly-named variables as arguments easy: const x = 1; // Usually a complex computation instead. const y = 2 * x; return foo({x, y});
- VHRanger 2y agoI got tremendously sad when I watched Guy Steele's talk growing a language: https://www.youtube.com/watch?v=_ahvzDzKdB0 https://www.youtube.com/watch?v=_ahvzDzKdB0 It's one of the best programming talks I've come across. For 1998, all his points on growing a new programming language are spot on. And then Java became the opposite of a lot of the goals he enumerated.
- relaxing 2y agoHaving named parameters is such a revelation. And what do we get instead? Added features that make the language more complicated.
- NegativeLatency 2y agoOr the sorta annoying, un-ergonomic builder pattern: https://www.baeldung.com/java-builder-pattern https://www.baeldung.com/java-builder-pattern
- impure 2y agoAnd Go :(
- assbuttbuttass 2y agoFortunately you can use an options struct which retains most of the benefits of named parameters
- qw 2y agoIf the method takes so many arguments that named parameters is necessary for readability, it is often a sign that the method is either too complex and should be split up, or that the method should accept a "config" record as a parameter. I this makes it clearer because you can group the parameters and give them meaning. Then you know that "url", "headers" and "body" belongs to the "request" record, while "customerId" and "taskId" are separate