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 <[email protected]> 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:* [email protected] > *Sent:* June 22, 2017 1:14 PM > *To:* [email protected] > *Cc:* [email protected] > *Subject:* Re: Allowing object field name shorthand > > On Thu, Jun 22, 2017 at 5:53 PM, Sebastian Malton <[email protected]> > 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 >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
