Template literal property names in object literals

Isiah Meadows contact at isiahmeadows.com
Fri Nov 8 04:49:36 UTC 2019


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
contact at isiahmeadows.com
www.isiahmeadows.com

On Thu, Nov 7, 2019 at 4:23 PM Alex Kodat <akodat at rocketsoftware.com> 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 <me at gus.host>
> Sent: Thursday, November 7, 2019 3:13 PM
> To: Alex Kodat <akodat at rocketsoftware.com>
> Cc: Jordan Harband <ljharb at gmail.com>; es-discuss at mozilla.org
> 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:akodat at rocketsoftware.com> 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:ljharb at gmail.com>
> Sent: Thursday, November 7, 2019 2:44 PM
> To: Alex Kodat <mailto:akodat at rocketsoftware.com>
> Cc: Gus Caplan <mailto:me at gus.host>; mailto:es-discuss at mozilla.org
> 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:akodat at rocketsoftware.com> 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:ljharb at gmail.com>
> Sent: Thursday, November 7, 2019 1:46 PM
> To: Alex Kodat <mailto:mailto:akodat at rocketsoftware.com>
> Cc: Gus Caplan <mailto:mailto:me at gus.host>; mailto:mailto:es-discuss at mozilla.org
> 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:akodat at rocketsoftware.com> 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:me at gus.host>
> Sent: Thursday, November 7, 2019 11:13 AM
> To: Alex Kodat <mailto:mailto:mailto:mailto:akodat at rocketsoftware.com>
> Cc: mailto:mailto:mailto:mailto:es-discuss at mozilla.org
> 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:akodat at rocketsoftware.com> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list