Just wanted to chime in with the fact this has been a thing in
CoffeeScript for most (if not all) its existence, as well as with Ruby
hash maps, which special-case string keys (you can do
`{"foo#{bar}baz": whatever}`).Not that I would expect this to have much impact on whether this really minor nice-to-have makes it in, though... ----- Isiah Meadows [email protected] www.isiahmeadows.com On Thu, Nov 7, 2019 at 4:23 PM Alex Kodat <[email protected]> wrote: > > Gus, > > Sure, but your (const) example is simply syntactically invalid – > syntactically invalid code will always be hard for humans to digest. A better > example might be one involving operator precedence – I’ll plead guilty to > adding unnecessary parentheses so someone looking at code doesn’t have to > waste cycles thinking through operator precedence issues. > > But, in any case, I don't think human would find: > > let obj = {`foo bar`: 1} > > or even > > let obj = {`foo${i}`: 1} > > daunting to parse. And if it upsets them, just like I add unnecessary > parantheses to my code, they could do > > let obj = {[`foo${i}`]: 1} > > if they feel that somehow makes the code clearer (it gives me a headache ;-)). > > Thanks > > ------ > Alex Kodat > Senior Product Architect > Rocket Software > t: +1 781 684 2294 • m: +1 315 527 4764 • w: http://www.rocketsoftware.com/ > > From: Gus Caplan <[email protected]> > Sent: Thursday, November 7, 2019 3:13 PM > To: Alex Kodat <[email protected]> > Cc: Jordan Harband <[email protected]>; [email protected] > Subject: Re: Template literal property names in object literals > > Syntactic ambiguities are not very representative of what humans find > ambiguous. For example, `const x = 1 const x = 2` (no semicolon) is not > ambiguous to a parser at all, but humans have a hard time tracking it. > > On Thu, Nov 7, 2019 at 12:53 PM Alex Kodat <mailto:[email protected]> > wrote: > Jordan, > > That’s not an ambiguity, it’s just a rule of thumb that’s currently true. No? > My question is whether adding TemplateString to ComputedPropertyName in the > spec would create **syntactic** ambiguities or daunting implementation issues. > > Clearly, there's little interest in this so I'll drop it, I was just curious > as I, at least, was somewhat surprised to see it didn't work. > > Thanks > > ------ > Alex Kodat > Senior Product Architect > Rocket Software > t: +1 781 684 2294 • m: +1 315 527 4764 • w: > https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2F&data=02%7C01%7C%7Ce77faaad7c8444d9792f08d763c74e54%7C79544c1eed224879a082b67a9a672aae%7C0%7C1%7C637087579982532174&sdata=wl5HN9LEKavzBGkxJf0SugC2iN2oOQu12kmnXKUkXoo%3D&reserved=0 > > From: Jordan Harband <mailto:[email protected]> > Sent: Thursday, November 7, 2019 2:44 PM > To: Alex Kodat <mailto:[email protected]> > Cc: Gus Caplan <mailto:[email protected]>; mailto:[email protected] > Subject: Re: Template literal property names in object literals > > It would create the ambiguity that "every property name not in brackets is > static/hardcoded" is no longer true. > > On Thu, Nov 7, 2019 at 12:14 PM Alex Kodat > <mailto:mailto:[email protected]> wrote: > Jordan, > > The sentiments in that link discuss the wisdom of having the StringLiteral > definition include NoSubstitutionTemplate, a question about which I am > agnostic, and wouldn't provide the full functionality I'm asking about, > anyway. > > And I also understand that the spec currently only allows computed property > names in square brackets. > > My suggestion was that ComputedPropertyName *could* be changed to include > TemplateString (without square brackets). Whether this is worth doing or > paints JS syntax into a corner is a fair question, but I don't see that > adding TemplateString to ComputedPropertyName would create any syntactic > ambiguities and wouldn't seem to present daunting implementation issues. But > maybe this last assertion is incorrect and ambiguities would arise or > implementation would be a nightmare? > > Thanks > > ------ > Alex Kodat > Senior Product Architect > Rocket Software > t: +1 781 684 2294 • m: +1 315 527 4764 • w: > https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2F&data=02%7C01%7C%7Ce77faaad7c8444d9792f08d763c74e54%7C79544c1eed224879a082b67a9a672aae%7C0%7C1%7C637087579982532174&sdata=wl5HN9LEKavzBGkxJf0SugC2iN2oOQu12kmnXKUkXoo%3D&reserved=0 > > From: Jordan Harband <mailto:mailto:[email protected]> > Sent: Thursday, November 7, 2019 1:46 PM > To: Alex Kodat <mailto:mailto:[email protected]> > Cc: Gus Caplan <mailto:mailto:[email protected]>; > mailto:mailto:[email protected] > Subject: Re: Template literal propery names in object literals > > Anything dynamic - computed - should be in brackets, since that's what that > indicates. > > Thus, template literals with substitutions must require brackets. > > Based on sentiments like > https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftc39%2Fecma262%2Fissues%2F1399%23issuecomment-452910799&data=02%7C01%7C%7Ce77faaad7c8444d9792f08d763c74e54%7C79544c1eed224879a082b67a9a672aae%7C0%7C1%7C637087579982542161&sdata=V%2BzJuiHgRE6plHXA5lyY4xhlhv4O5%2Fvl6UTc1yeaRzk%3D&reserved=0, > either all template literals or none should be permitted in a given position. > > Thus, no change is possible. > > On Thu, Nov 7, 2019 at 10:00 AM Alex Kodat > <mailto:mailto:mailto:mailto:[email protected]> wrote: > Thanks Gus, > > Good stuff. Though I think I’d take a different tack on the discussion at > that link, especially as I think the template literals should allow > substitutions (why not?): > > let obj = { `${Date()}`: 1}; > > I guess the tack I would take in the spec would be to add TemplateLiteral to > ComputedPropertyName and not worry about whether or not it's a > NoSubstitutionTemplate. > > Thanks > > ------ > Alex Kodat > Senior Product Architect > Rocket Software > t: +1 781 684 2294 • m: +1 315 527 4764 • w: > https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2F&data=02%7C01%7C%7Ce77faaad7c8444d9792f08d763c74e54%7C79544c1eed224879a082b67a9a672aae%7C0%7C1%7C637087579982542161&sdata=oWJOeksC4idx7j4ffoOjNMiT6oXmY8XmVaAgQJnmHPM%3D&reserved=0 > > From: Gus Caplan <mailto:mailto:mailto:[email protected]> > Sent: Thursday, November 7, 2019 11:13 AM > To: Alex Kodat <mailto:mailto:mailto:mailto:[email protected]> > Cc: mailto:mailto:mailto:mailto:[email protected] > Subject: Re: Template literal propery names in object literals > > Related discussion > https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftc39%2Fecma262%2Fissues%2F1399&data=02%7C01%7C%7Ce77faaad7c8444d9792f08d763c74e54%7C79544c1eed224879a082b67a9a672aae%7C0%7C1%7C637087579982552157&sdata=Lm5ZzlaIBiRhWfI%2B3NM7q6WN4R9zeDtak5eb1L8nD5A%3D&reserved=0 > > On Thu, Nov 7, 2019 at 8:46 AM Alex Kodat > <mailto:mailto:mailto:mailto:mailto:mailto:mailto:[email protected]> > wrote: > Just curious. Is there a reason template literals are not allowed as property > names in object literals? I can do: > > let obj = {'foo bar': 1}; > > and > > let obj = {"foo bar": 1}; > > but not > > let obj = {`foo bar`: 1}; > > It doesn't seem that allowing the latter would present any syntactic problems > and seems like almost an oversight that it's not allowed. > > The main reason I ask is that we've gone completely over to using template > literals for all our literals (why not?) and was surprised that we can't use > a template literal as an object literal property name. Obviously, we can do: > > let obj = {[`foo bar`]: 1}; > > And given that square brackets allow arbitrary expressions for propery names, > it wouldn't seem that supporting template literals for object literal > property names would not present any daunting implementation issues. > > I guess I'd argue that the Principle of Least Astonishment and/or > completeness suggests that JS should support this. > > Sorry if this has been asked before but couldn't find anything in the archive. > > Thanks > > [snip url junk] > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
