Picking (deconstructing) properties into object literals

[Naveen Chawla]

The motivation for destructuring is to tersely do algorithmic stuff using a
value from an object, e.g.

```
const {x, y} = coordinates
//Do a whole bunch of stuff using x here...
```

It seems to me, that destructuring into an object loses the whole purpose
of destructuring, e.g.:

```
const coordinates =
    {
        {x, y} = coordinates
    }
//You still have to access x via coordinate.x, and that's in the best case
```

Otherwise if there were cases where it would genuinely save code then I
would be all for it

On Wed, 23 Aug 2017 at 18:06 Mark <mark at heyimmark.com> wrote:

> Definitely agree with isiah and kai. The proposal original mentioned is
> not as readable as its less-terse counterparts. I'm all for less code that
> does more, but not at the expense of not being able to easily look at the
> code and understand what's going on.  And if not, there had better be a
> good reason to introduce it into the spec. Hope this helps!
>
> On Wed, Aug 23, 2017, 12:45 AM kai zhu <kaizhu256 at gmail.com> wrote:
>
>> -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 <isiahmeadows at gmail.com>
>> 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
>> me at isiahmeadows.com
>>
>> 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 <rtm at gol.com> 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
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170823/7dddd551/attachment-0001.html>