inline counter-rant. > On Feb 8, 2018, at 9:04 PM, Bob Myers <r...@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 <isiahmead...@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.c...@gmail.com > <mailto:naveen.c...@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.c...@gmail.com > <mailto:naveen.c...@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@mozilla.org <mailto:es-discuss@mozilla.org> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss> > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org <mailto:es-discuss@mozilla.org> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss>
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
