Hacker News Reader

Comment by bluefirebrand | Hacker News Reader

Named parameters are easy enough to mimic in JS using objects and the spread operation

function foo({bar, baz}) { ... }

foo({bar: 1, baz: false})

I'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.

I 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.

Lemme be an absolute pedant and say that's destructuring, not spreading.

And correct me if I'm wrong, nothing worse than an incorrect pedant.

I'm not sure, but I think homicide might be worse than an incorrect pedant.

Well done.

Is the so-called victim the pedant in question?

that'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

TypeScript is the answer.

Is there anything wrong with taking a single parameter?

Never 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.

This 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.

Reply on news.ycombinator.com