> Some people on a web site are curious to know if they can reduce 2 lines
of JS code to 1 line

Right, some people wanted to reduce 2 lines of JS code

```
const a = o.a;
const b = o.b;
```

to 1 line

```
const {a, b} = o;
```

and that's how we ended up with destructuring assignment, which managed to
make its way into the spec. Actually it's not just one less line; it's more
semantic and readable and less bug-prone.

I'm not giving excessive weight to the questions of a few folks on
StackOverflow, but it is curious how frequent and obvious the questions of
these real people writing real code are: "If I can deconstruct into
variables, why can't I deconstruct into objects?"

It's worth pointing out that on a scale of 0 to 100 of syntactical
"newness", this proposal ranks quite low. We're not introducing new
operators, for example. We're adding the option to specify existing
deconstructing syntax after the existing dot syntax to obtain an object
with those deconstructed properties.

Another answer to this thread suggested that picking properties into a new
object could be handled by userland code. Sure it could, and already is, in
the form of Underscore's `_.pick` etc. Yes, this is syntactic sugar. So is
deconstructing assignment.

But it's a tiny bit more than mere syntactic sugar. Writing `obj.{p1, p2}`
is just sugar for writing `{p1: obj.p1, p2: obj.p2}`. But I can also write
`obj.{p1: q1, p2 = 100}` to take advantage of the familiar ability of
deconstructing syntax to rename and specify defaults, not to mention
picking deeply, or using computed property names. That is something that
would be very hard to implement in a userland function--ok, maybe not
difficult, but cumbersome--do you really want to specify deep picks as
`"a.b.c"`?. And it would be a real challenge to write a TypeScript
signature for any version of `_.pick`, much less one that handled renaming,
defaults, and deep picking.

I totally agree with Matthew Robb's comment in a separate response that
this proposal is not imposing a new cognitive burden; it's REMOVING the
cognitive burden of wondering why our handy deconstructing syntax cannot be
used to pick properties into objects.

--
Bob






On Wed, Sep 21, 2016 at 8:10 PM, Jason Orendorff <jason.orendorff at gmail.com>
wrote:

> On Tue, Sep 20, 2016 at 2:38 PM, Bob Myers <rtm at gol.com> wrote:
>
>> People in the real world continue to wonder why they can't
>> pick/destructure from objects into objects, instead of just variables.
>>
>> http://stackoverflow.com/questions/39602360/es6-destructurin
>> g-reassignment-of-object?noredirect=1#39602360
>>
>> This is actually the second such question on SO in the last week.
>>
>
> Well, this not as weighty a consideration as you might think.
>
> Some people on a web site are curious to know if they can reduce 2 lines
> of JS code to 1 line. Their shared curiosity may be a coincidence; or it
> may be the language's fault. Presume the latter. It doesn't follow that the
> answer should be yes. Since all new syntax imposes some mental load on all
> language users, the answer should be no unless the benefit is really
> dramatic, which I don't think it is here.
>
> -j
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160922/d2dd1bc5/attachment.html>

> Some people on a web site are curious to know if they can reduce 2 lines
of JS code to 1 line

Right, some people wanted to reduce 2 lines of JS code

```
const a = o.a;
const b = o.b;
```

to 1 line

```
const {a, b} = o;
```

and that's how we ended up with destructuring assignment, which managed to
make its way into the spec. Actually it's not just one less line; it's more
semantic and readable and less bug-prone.

I'm not giving excessive weight to the questions of a few folks on
StackOverflow, but it is curious how frequent and obvious the questions of
these real people writing real code are: "If I can deconstruct into
variables, why can't I deconstruct into objects?"

It's worth pointing out that on a scale of 0 to 100 of syntactical
"newness", this proposal ranks quite low. We're not introducing new
operators, for example. We're adding the option to specify existing
deconstructing syntax after the existing dot syntax to obtain an object
with those deconstructed properties.

Another answer to this thread suggested that picking properties into a new
object could be handled by userland code. Sure it could, and already is, in
the form of Underscore's `_.pick` etc. So yes, this is syntactic sugar. But so is
deconstructing assignment.

But it's a tiny bit more than mere syntactic sugar. Writing `obj.{p1, p2}`
is just sugar for writing `{p1: obj.p1, p2: obj.p2}`. But I can also write
`obj.{p1: q1, p2 = 100}` to take advantage of the familiar ability of
deconstructing syntax to rename and specify defaults, not to mention
picking deeply, or using computed property names. That is something that
would be very hard to implement in a userland function--ok, maybe not
difficult, but cumbersome--do you really want to specify deep picks as
`"a.b.c"`?. And it would be a real challenge to write a TypeScript
signature for any version of `_.pick`, much less one that handled renaming,
defaults, and deep picking.

I totally agree with Matthew Robb's comment in a separate response that
this proposal is not imposing a new cognitive burden; it's REMOVING the
cognitive burden of wondering why our handy deconstructing syntax cannot be
used to pick properties into objects.

--
Bob

> Some people on a web site are curious to know if they can reduce 2 lines
of JS code to 1 line

Right, some people wanted to reduce 2 lines of JS code

```
const a = o.a;
const b = o.b;
```

to 1 line

```
const {a, b} = o;
```

and that's how we ended up with destructuring assignment, which managed to
make its way into the spec. Actually it's not just one less line; it's more
semantic and readable and less bug-prone.

I'm not giving excessive weight to the questions of a few folks on
StackOverflow, but it is curious how frequent and obvious the questions of
these real people writing real code are: "If I can deconstruct into
variables, why can't I deconstruct into objects?"

It's worth pointing out that on a scale of 0 to 100 of syntactical
"newness", this proposal ranks quite low. We're not introducing new
operators, for example. We're adding the option to specify existing
deconstructing syntax after the existing dot syntax to obtain an object
with those deconstructed properties.

Another answer to this thread suggested that picking properties into a new
object could be handled by userland code. Sure it could, and already is, in
the form of Underscore's `_.pick` etc. Yes, this is syntactic sugar. So is
deconstructing assignment.

But it's a tiny bit more than mere syntactic sugar. Writing `obj.{p1, p2}`
is just sugar for writing `{p1: obj.p1, p2: obj.p2}`. But I can also write
`obj.{p1: q1, p2 = 100}` to take advantage of the familiar ability of
deconstructing syntax to rename and specify defaults, not to mention
picking deeply, or using computed property names. That is something that
would be very hard to implement in a userland function--ok, maybe not
difficult, but cumbersome--do you really want to specify deep picks as
`"a.b.c"`?. And it would be a real challenge to write a TypeScript
signature for any version of `_.pick`, much less one that handled renaming,
defaults, and deep picking.

I totally agree with Matthew Robb's comment in a separate response that
this proposal is not imposing a new cognitive burden; it's REMOVING the
cognitive burden of wondering why our handy deconstructing syntax cannot be
used to pick properties into objects.

--
Bob