-1
this is a terrible idea in terms of debugging and code-maintennance.  when
debugging someone else's unfamiliar code, i now have to add an extra-check
for quotes around the key.
On Jun 23, 2017 1:36 AM, "T.J. Crowder" <tj.crow...@farsightsoftware.com>
wrote:

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

Reply via email to