Discuss
  • Object literal syntax for dynamic keys

Object literal syntax for dynamic keys

# Jussi Kalliokoski (12 years ago)

This is almost purely a syntactic sugar proposal, and if there's already a proposal like this being/been discussed, please point me that way, I couldn't find anything. Anyway, the use case is as follows:

You have keys that come, for example from a config file or are defined as constants, and you want to create objects with those keys. What you currently have to do is to use a mix of object notation syntax and assignment:

myObject = {
  someKey: 'someValue'
};
myObject[MY_KEY_ID] = 'my value';

This is usually ok, but it's a bit confusing to read especially if the object is long and you try to find the definition inside the brackets but can't. Also, as far as I know, "someKey" and MY_KEY_ID end up being defined differently; I doubt that the latter matters much, but what I have in mind would fix both things:

myObject = {
  someKey: 'someValue',
  [MY_KEY_ID]: 'my value'
};

So basically you could use brackets to signify that the key is the value of an expression inside the brackets.

# David Bruant (12 years ago)

2013/7/19 Jussi Kalliokoski <jussi.kalliokoski at gmail.com>

myObject = {
  someKey: 'someValue',
  [MY_KEY_ID]: 'my value'
};

I believe this is already proposed at harmony%3Aobject_literals#object_literal_computed_property_keys

# Rick Waldron (12 years ago)

These are computed properties and Allen has already added them to the latest ES6 draft.

ComputedPropertyName :
  [ AssignmentExpression ]
# Kevin Smith (12 years ago)

Yes - but I believe computed property names are currently spec'ed to throw if the assignment expression evaluates to something other than a symbol

# Rick Waldron (12 years ago)

On Fri, Jul 19, 2013 at 9:10 AM, Kevin Smith <zenparsing at gmail.com> wrote:

Yes - but I believe computed property names are currently spec'ed to throw if the assignment expression evaluates to something other than a symbol

Can you point to where the current spec draft specifies this—I don't see it.

# Kevin Smith (12 years ago)

Sure - page 129 of the latest draft:

ComputedPropertyName : [ AssignmentExpression ]

  1. Let exprValue be the result of evaluating AssignmentExpression.
  2. Let propName be GetValue(exprValue).
  3. ReturnIfAbrupt(propName).
  4. If propName is not an exotic Symbol Object, then a. Throw a TypeError exception.
  5. Return propName.
# Till Schneidereit (12 years ago)

On Fri, Jul 19, 2013 at 5:11 PM, Kevin Smith <zenparsing at gmail.com> wrote:

This isn't yet a final decision, however:

esdiscuss.org/topic/on-ie-proto-test-cases#content

# Allen Wirfs-Brock (12 years ago)

right, this is listed in the agenda for the next TC39 meeting

If anybody can find in the TC39 meeting notes this was last discussed, that would be helpful. I think in was in 2011 or early 2012.

# Rick Waldron (12 years ago)

On Fri, Jul 19, 2013 at 11:32 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

If anybody can find in the TC39 meeting notes this was last discussed, that would be helpful. I think in was in 2011 or early 2012.

Potentially relevant:

# Jussi Kalliokoski (12 years ago)

Excellent, thanks!

I need to up my archive searching skills...

Anyway, I think it might be worth it to extend the syntax to support more than just symbols. For my cases, symbols will do the job, however for example for externally defined (e.g. config file) key names it would be quite handy to have calculated string keys as well.

How relevant is the object model reformation nowadays since we've decided that collections use get()/set() methods instead of accessors?