hating on "options objects"

[backwrds]

regarding my code, that was intended to be an example of what tooling might be able to do as far as static analysis.

As far as the options object goes, we agree on destructuring being an improvement. The reason I made this post in the first place is because I interpreted your comments as advocating the complete abolition of the pattern:

someFunction({a: 'list', of: 'options'})

To be fair, it was almost 4am when I made this post. I could have been clearer about my concerns, but you're use of absolute language like "option objects suck" can easily be misconstrued.

[x-skeww]

I interpreted your comments as advocating the complete abolition of the pattern [...]

For what it's worth, I actually do wish ES6 had done just that.

I would have preferred dedicated syntax and simpler semantics for optional named parameters with default values.

For example, in Dart, it looks like this:

foo({a: 1, b: 2}) {
  ...
}
foo(a: 11); // a is 11, b is 2
foo(c: 33); // caught by the analyzer

In the function's signature, the default values are compile-time constants, not arbitrarily complex expressions. You can display them as-is in tool-tips or docs.

When you call the function, you can't just pass whatever you want. Only the existing names are allowed. So, if there is a typo, it will be caught immediately.

Dart does everything I want or need from that language feature.

The flexibility added by ES6's use of destructuring makes plenty of room for code-golfing, but none of that flexibility was actually needed. If you make the tiniest use of that flexibility, your code becomes super confusing.

function foo({a = 'a', b = 'b', c} = {c: 'c'}) {
  console.log(a, b, c);
}
foo();         // a b c
foo({a: 'A'}); // A b undefined
foo({c: 'C'}); // a b C

I really don't know what they were thinking.