4 ms·
Named parameters are easy enough to mimic in JS using objects and the spread operation function foo({bar, baz}) { ... } foo({bar: 1, baz: false})
by bluefirebrand 2y ago
Named 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.