Sure, I would say that the easiest benefit would be the shorthand. I have shown it to people and it apparently help with mongo integration. 1. I don't think that hidden behaviours is necessarily bad. It is not like this is an inconsistent from reassignment and adding a new level to the object 2. In my opinion the notation of {"n.b": 1} should equate to {n.b: 1} so that object field retrieval is consistent. 3. I definitely see the slight complexity of this new method however I would see that the easiest solution would be to do each line in order checking to see if the sub object does not exist or is of type object and not of type array (unless you call "push" I see). I would say that it would be a runtime error sort of like "you cannot set property of undefined" but instead it would be "you cannot set property of null" or "number" . 4. I also believe that this sort of thing could make configs easier to read Sebastian
Can you expand on the benefits vs. costs (e.g., complexity, clarity)? I ask because I'm not immediately seeing a lot of benefit, but I'm seeing various costs: 1. It adds more hidden behavior (creating the object). 2. It makes object initializers more confusing to human readers. The syntaxes `{"a.b": 42}` and `{[a.b]: 42}` are already both valid, and do quite different things from each other; adding `{a.b: 42}` with yet a third, different, behavior seems problematic (to me). The benefits of computed property names were strong enough to justify the second syntax above, but are the benefits of this sufficient for a third? 3. It adds complexity to object initializer processing, both in the obvious way (has to figure out to create the hidden object or possibly several nested hidden objects), and around the fact that object initializers are processed in source code order. Re that third point, consider this code using this new notation: ```js const o = { a.a: one(), b: two(), a.b: three() }; ``` Those functions should be called in the order `one`, `two`, `three`, which means adding to the object on `a` later on in the initializer; it can't just become: ```js const o = { a: { // WRONG a: one(), b: three() }, b: two() }; ``` ...because `three` would be called before `two`. I suppose the logic could still be source code order, and the engine would break apart the identifier, check to see if the first part already exists on the object and use its value if so, add an object if not; rinse, repeat. If so, it raises the question: ```js const o = { a: 1, a.b: 42 }; ``` Is that a syntax error? *(No, wait, it can't be; `1` could be any _expression_.)* A runtime error? A silent runtime failure as `const o = {a: 1}; a.b = 42;` would be? Suppose we changed `a: 1` to `a: null`? `const o = {a: null}; a.b = 42;` would throw, should this new syntax throw in that case? Weighed against those, the only real benefit I see is that it's *slightly* more concise in the case of an object with a single property; but as of even a second property, it's more verbose. Sorry, this ran longer than I meant it to. Not trying to bash the idea, these are just the things that jumped out at me and I type fairly quickly. :-) -- T.J. Crowder On Thu, Jun 22, 2017 at 3:56 PM, Sebastian Malton <sebast...@malton.name> wrote:
| ||
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
