Suggestion: Destructuring object initializer.

[kai zhu]

inline counter-rant.

> On Feb 8, 2018, at 9:04 PM, Bob Myers <rtm at gol.com> wrote:
> 
> It does make one stop and wonder why the group will endlessly entertain trolls debating whether or not ES6 (or ES5) portends the end of civilization as we know it, while relentlessly ignoring literally dozens of similar/identical proposals for property picking, a feature which easily contributes as much to the language at as little cost as many other features such as spread properties.

because most language-proposals *are* not important (or worse distractions) when you look at the really hard engineering-problems javascript was built to solve: UX design and [async] UX workflows (which are outside the comfort-zone of most engineers). people who have zero-empathy for UX are generally not going to become successful javascript-programmers (and their javascript-language opinions weighted accordingly). many just end up creating “correct” but non-user-friendly tools and libraries that no frontend-engineer wants to touch.

companies do not hire laid-off engineers retrained as javascript-programmers so they can continue doing the things that made them redundant, like working on micro-solutions to “hard” cs-problems beaten-to-death by college-professors, that many times end up as re-inventions no better off than sqlite3.  they hire javascript-programmers to solve higher-level UX problems, such as writing the necessary messy/ugly integration-code to leverage existing good-enough data-structures like sqlite3 into a UX solution like a persistent amazon shopping-cart, or facebook image-uploader.  destructuring doesn’t solve UX problems or add value to employers hiring javascript-programmers.  its a negative-productivity language-feature that makes already messy integration-code even harder to read, especially for those trying to debug code not written by themselves.

-kai

> On Feb 11, 2018, at 6:33 AM, Isiah Meadows <isiahmeadows at gmail.com> wrote:
> 
> 
> Another common reaction is "big deal, saving a few characters or lines". But more than one recent language feature also falls into this category of mainly or purely sugar and brevity. For instance, property spread syntax is pretty much just sugar for `Object.assign`, yet everyone seems to think it's the best thing since sliced bread.
> 
> My understanding of this differs:
> 
> - It was to bring feature parity with array spread destructuring.
> - The proposal included both merging and extracting.
> - It actually optimized for an exceptionally common case (React circles benefitted the most, but others did quite a bit, too), immutable update of record-like objects. In my experience, that scenario is *more* common than array spread (beyond rest parameters), and engines can optimize for objects that are not referenced elsewhere by not actually copying them, something harder to do with `Object.assign`.\*
> - You *could* implement it via `Object.assign`, but it chopped the number of characters down to less than half for most cases if you're not just merging. Most of these pick proposals aren't coming close.
> 
> \* I don't know/believe if they do, but it's pretty easy to implement with type info.
> 
> 
> Bob
> 
> On Sat, Feb 10, 2018 at 10:07 AM, Naveen Chawla <naveen.chwl at gmail.com <mailto:naveen.chwl at gmail.com>> wrote:
> Sorry sent by accident before my message was edited properly. My basic point was that since curly braces are used for both destructuring and object literals, there's an issue with being able to glance at the code and quickly discern what's happening if they are mixed together in the same piece of syntax. Not impossible, just a potential source of bugs and/or delay in understanding the data structure being declared.
> 
> On Sat, 10 Feb 2018 at 10:01 Naveen Chawla <naveen.chwl at gmail.com <mailto:naveen.chwl at gmail.com>> wrote:
> I'm not a TC39 member, but I have a little readability issue with destructuring inside an object:
> 
> ```js
> { {p1, p2} = p, {q1, q2} = q }
> ```
> 
> has a very different meaning than
> 
> ```js
> { p: {p1, p2}, {q1, q2} = q }
> ```
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180211/0b54cda9/attachment.html>