New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamic object keys #786

Closed
satyr opened this Issue Oct 21, 2010 · 19 comments

Comments

Projects
None yet
@satyr
Copy link
Collaborator

satyr commented Oct 21, 2010

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

This comment has been minimized.

Copy link
Contributor

StanAngeloff commented Oct 21, 2010

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

This comment has been minimized.

Copy link
Collaborator

satyr commented Oct 21, 2010

"#{key}": val

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

@StanAngeloff

This comment has been minimized.

Copy link
Contributor

StanAngeloff commented Oct 21, 2010

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

This comment has been minimized.

Copy link
Collaborator

TrevorBurnham commented Oct 22, 2010

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

This comment has been minimized.

Copy link
Collaborator

satyr commented Oct 22, 2010

Note that there is a precedence.

@TrevorBurnham

This comment has been minimized.

Copy link
Collaborator

TrevorBurnham commented Oct 22, 2010

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

This comment has been minimized.

Copy link
Collaborator

satyr commented Oct 24, 2010

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

This comment has been minimized.

Copy link
Owner

jashkenas commented Oct 24, 2010

Merged to master.

@yfeldblum

This comment has been minimized.

Copy link

yfeldblum commented Nov 2, 2010

Nice!

@pyrotechnick

This comment has been minimized.

Copy link

pyrotechnick commented Dec 7, 2010

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

This comment has been minimized.

Copy link
Owner

jashkenas commented Dec 7, 2010

Sure thing: 4cab45c

@pyrotechnick

This comment has been minimized.

Copy link

pyrotechnick commented Aug 16, 2011

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

@pyrotechnick

This comment has been minimized.

Copy link

pyrotechnick commented Sep 28, 2011

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

This comment has been minimized.

Copy link

mikermcneil commented Jan 18, 2015

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

very true

@joaomilho

This comment has been minimized.

Copy link

joaomilho commented Feb 23, 2015

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

This comment has been minimized.

Copy link

Spadavecchia commented Mar 18, 2015

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

This comment has been minimized.

Copy link
Collaborator

lydell commented Mar 18, 2015

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

@Spadavecchia

This comment has been minimized.

Copy link

Spadavecchia commented Mar 18, 2015

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

@vendethiel

This comment has been minimized.

Copy link
Collaborator

vendethiel commented Mar 18, 2015

yes. #3840

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment