-1 and agree with isiah furthermore, i see javascript deconstruction as a never-ending can-of-worms that too-often devolves into ruby-esque confusion / arguments over the “best” way to do assignments. NO AMOUNT of language-spec changes will resolve all these arguments, so forget about it.
p.s. the principle of avoiding language-spec changes that snowball into necessitating future language-spec changes, when established good-enough solutions already exist, should be used more often by tc39 (and also avoid needlessly de-optimizing engine-implementations and making the overall world-wide-web slower). > On Aug 23, 2017, at 12:36 PM, Isiah Meadows <[email protected]> wrote: > > Honestly, I'm not sure how necessary this really is. `_.pick` exists > in Lodash, Underscore, and Ramda, but I'm not seeing it in persistent > data structure libraries like Immutable.js [1] or Mori [2], where it > would seemingly be *more* critical. > > [1]: https://facebook.github.io/immutable-js/docs/#/Map > [2]: https://swannodette.github.io/mori/ > > For what it's worth, with those libraries, if you'd want something > like `pick`, you could use something like this: > > ```js > // Immutable.js > function pick(map, keys) { > return map.filter((_, key) => keys.includes(key)) > } > > // Mori > function pick(map, ...keys) { > return mori.reduce( > (acc, key) => mori.assoc(acc, key, mori.get(map, key)), > mori.hashMap(), keys) > } > ``` > ----- > > Isiah Meadows > [email protected] > > Looking for web consulting? Or a new website? > Send me an email and we can get started. > www.isiahmeadows.com > > > On Tue, Aug 22, 2017 at 11:22 PM, Bob Myers <[email protected]> wrote: >> Extending the ways we can construct object literals has been a sort of theme >> in JS language design recently, with shorthand object notation in ES6, and >> now spread properties. The motivations include conciseness and readability. >> >> With destructuring assignment, the community decided it made sense to add >> syntax to easily destructure selected properties of an object into >> variables. With spread properties, the community is deciding it makes sense >> to add syntax to easily include all properties from one object into an >> object literal. The missing piece is the ability to include selected >> properties of an object into an object literal. >> >> When asked by people we are mentoring or teaching how to create an object >> containing selected properties from other objects (which happens with >> surprising frequency), we usually just tell them to write >> >> ```js >> {p: a.p, q: a.q, r: b.r, s: b.s} >> ``` >> >> Or sometimes >> >> ```js >> const {p, q} = a; >> const {r, s} = b; >> const newObj = {p, q, r, s}; >> ``` >> >> Neither of which is ideal. In this proposal, we allow the following syntax: >> >> ```js >> { {p, q} = a, {r, s} = b } >> ``` >> >> Here, the `{p, q} = a` is exactly the same production as the spec's >> *AssignmentExpression**, as used in destructuring assignment. That includes >> the ability to rename properties (`{q1: q2} = a}`), specify defaults (`{q1 = >> 42} = a`), and pick out nested properties (`{q1: {q11}} = a`). In other >> words, we take full advantage of the power of current destructuring >> assignment syntax when picking properties into object literals. The sole new >> syntactic aspect in this proposal is the ability to place the >> *AssignmentExpression* construct *inside* an object literal. >> >> A fuller description of this proposal can be found at >> https://github.com/rtm/js-pick-notation. >> >> -- >> Bob >> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
