Dynamic object keys

[satyr]

By allowing parenthesized expression as keys, we could write:

return {(key): val}

instead of:

o = {}
o[key] = val
return o

The compilation would be:

return (_obj = {}, _obj[key] = val, _obj);

Not sure if we can go braceless with it, but worth a try.

[StanAngeloff]

I've wanted to do this, but using string interpolations. Wouldn't that be the proper way to do it rather than introducing an alternative syntax inconsistent with JavaScript?

return { "#{key}": val }

into

return (_result = {}, _key = ("" + (key)), _result[_key] = value, _result);

[satyr]

"#{key}": val

Lexer converts interpolated strings into parenthesized concatenations, so that's actually the same thing for parser.

[StanAngeloff]

I wrote that code and I don't remember it now, classic!

I like the proposal, we just need to settle on a syntax (ah, the never ending discussion).

[TrevorBurnham]

I like the string interpolation approach. Its meaning is immediately apparent, whereas interpreting things differently when wrapped in parentheses is a bit eccentric. Can we figure out a way to get this to work in the lexer/parser?

[satyr]

Note that there is a precedence.

[TrevorBurnham]

I like Groovy, but I still think the parentheses syntax is non-obvious.

Look at it from the other direction: Isn't it odd that {"key": val} works and "#{key}" works, but {"#{key}": val} is a syntax error? I'd go so far as to call that a bug.

[satyr]

http://github.com/satyr/coffee-script/compare/master...dynakeys

First stab without rewriter hack (requires braces).

Done I think.

$ bin/coffee -bpe 'o = "#{key}": val'
var _obj, o;
o = (_obj = {}, _obj["" + key] = val, _obj);

$ bin/coffee -bpe '{(a.b)} = c'
a.b = c[a.b];

[jashkenas]

Merged to master.

[yfeldblum]

Nice!

[525c1e21-bd67-4735-ac99-b4b0e5262290]

This was pulled from master in 4447180 which was released in CoffeeScript 0.9.6

@jashkenas perhaps you should add it to the changelog

[jashkenas]

Sure thing: 4cab45c

[525c1e21-bd67-4735-ac99-b4b0e5262290]

What was the issue with these dynamic object keys exactly? I miss them...

[525c1e21-bd67-4735-ac99-b4b0e5262290]

FYI

Sorry for being tardy -- if I remember correctly, it was because some of our other language features depend on having the key known at compile time. For example, method overrides and super calls in executable class bodies. We want to know the name of the key so that a proper super call can be constructed.

Also, it makes it so that you have to closure-wrap objects when used as expressions (the common case) whenever you have a dynamic key.

Finally, there's already a good syntax for dynamic keys in JavaScript which is explicit about what you're doing: obj[key] = value.

There's something nice about having the {key: value, key: value} form be restricted to "pure" identifiers as keys.

--jashkenas in #1731

[mikermcneil]

There's something nice about having the {key: value, key: value} form be restricted to "pure" identifiers as keys.

very true

[joaomilho]

There may be something nice, but it is not pragmatic. Look at React's React.addons.classSet for instance. It's meant to help defining a list of class names for a component. That's the way it works:

React.addons.classSet
  'classA': true
  'classB': hasClassB()
  'classC': hasClassC()

But most of the time you need dynamic keys (specially if you follow BEM), like:

React.addons.classSet
  "block__element#{if hasModifier() '--modifier' else '--no-modifier'}": true

[Spadavecchia]

obj = "#{someVar}": true

This is generating Unexpected : error in coffeelint and karma coffee-preprocessor.

You can write a comment # coffeelint: disable=coffeescript_error to avoid coffeelint error, but karma is not working.

[lydell]

@Spadavecchia Are you sure coffeelint and and karma use coffee-script 1.9.1?

[Spadavecchia]

@lidell, is true, that projects are using an old CS version, but should it to fail with version 1.7?

[vendethiel]

yes. #3840