Allowing object field name shorthand

[T.J. Crowder]

If you know it's already valid syntax, then why suggest it mean something
else? Breaking changes require **extremely compelling** justification (and
new language modes, à la strict mode, which I don't think there's any
appetite for at present).

I'm still not seeing any solid benefits to repeating the top-level field
name.

I'll step back at this point, I've raised the issues / concerns that came
to me.

Best,

-- T.J. Crowder


On Thu, Jun 22, 2017 at 6:25 PM, Sebastian Malton <sebastian at malton.name>
wrote:

> Okay, I know that "a.b" is already valid syntax but with the common field
> retrieval method this is inconsistent.
>
> ```js
> const obj = { "a.b" : 1 };
> const oak = { a : { b : 1 } };
>
> obj["a.b"] // This is the only way of getting this field
> oak.a.b
> oak["a"]["b"] // This object has as least two different ways.
> ```
>
> Currently not using quotes is valid method of defining field names but if
> you use quotes you can get names that look like they point to a sub object
>
> Sebastian
>
> *From:* tj.crowder at farsightsoftware.com
> *Sent:* June 22, 2017 1:14 PM
> *To:* sebastian at malton.name
> *Cc:* es-discuss at mozilla.org
> *Subject:* Re: Allowing object field name shorthand
>
> On Thu, Jun 22, 2017 at 5:53 PM, Sebastian Malton <sebastian at malton.name>
> wrote:
>
>> I would say that the easiest benefit would be the shorthand.
>>
>
> But as I pointed out, it's not shorthand unless the object only has one
> property. As of the second property, it's only more concise if the main
> property name is just one character; at two characters, it's a tie; and
> from three characters it's *less* concise. From three properties onward
> it's less concise even with a single-character top-level name:
>
> ```js
> // One property
> let o = {ex: {b: 1}};         // Current
> let o = {ex.b: 1};            // Proposed; shorter
> // Two properties, main property's name is only two characters:
> let o = {ex: {b: 1, c: 2}};   // Current
> let o = {ex.b: 1, ex.c: 2};   // Proposed; same
> // Two properties, main property's name is 3+ characters:
> let o = {foo: {b: 1, c: 2}};  // Current
> let o = {foo.b: 1, foo.c: 2}; // Proposed; longer
> // Three properties:
> let o = {a: {b: 1, c: 2, d: 3}};  // Current
> let o = {a.b: 1, a.c: 2, a.d: 3}; // Proposed; longer
> ```
>
> At that point it blossoms:
>
> ```js
> // Four properties
> let o = {a: {b: 1, c: 2, d: 3, e: 4}};    // Current
> let o = {a.b: 1, a.c: 2, a.d: 3, a.e: 4}; // Proposed; longer
> // Five properties
> let o = {a: {b: 1, c: 2, d: 3, e: 4, f: 5}};      // Current
> let o = {a.b: 1, a.c: 2, a.d: 3, a.e: 4, a.f: 5}; // Proposed; longer
> ```
>
> I have shown it to people and it apparently help with mongo integration.
>
>
> How, precisely?
>
>
>> 1. I don't think that hidden behaviours is necessarily bad.
>>
>
> We'll just have to disagree there. :-)
>
>
>> 2. In my opinion the notation of {"n.b": 1} should equate to {n.b: 1} so
>> that object field retrieval is consistent.
>>
>
> That's not going to happen. Again, `{"a.b": 1}` is *already* valid syntax.
> It creates an object with a property called `a.b` (which is a perfectly
> valid property name) with the value `1`. See: https://jsfiddle.net/nwyd
> gju2/
>
>
>> 4. I also believe that this sort of thing could make configs easier to
>> read
>>
>
> We'll have to disagree there, as well. :-) Moreover, making "configs" with
> JavaScript isn't really a goal, as far as I know.
>
> -- T.J. Crowder
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170622/aaf584b4/attachment.html>