I'm glad to see we are continuing to discuss this. It demonstrates some
degree of interest in the community for this feature, some degree of need.

With regard to Tab Adkins Jr.'s post:

> You can just write:

```
var d = {
  a,
  b,
  c: e.c
};
```

Yes, we know that, of course. You could also write `{a: a}`, but it was
decided that `{a}` was a nice shorthand. The question, as always, is how
commonly the situation arises (in my opinion: quite commonly), and how much
more compact the alternative is (in my opinion: reasonably more compact),
and/or what other benefits there might be (in this case, the benefit of not
mistyping one of the `c`'s).

>  and for a relatively small case (extracting a subset of the properties
of an object into another object, with the same key names).  That's usually not
a recipe for success. :(

There is no particular reason for believing that extracting a subset of the
properties of an object into another object is a smaller use case than
extracting the properties of an object into another object. Even if it less
common that extracting into variables, one can argue for it on grounds of
feature parity.

>  It's shorter to write, sure. But we can come up with special-purpose ways
to shorten code all day.

A classic fallacy, which if applied consistently would lead to rejecting
all proposals which are only or mainly syntax sugar. This ignores the fact
that a great number of ES6/7 features were/are in fact completely or at
least partially syntax sugar. Merely being syntax sugar does not constitute
a reason for rejecting something. It constitutes a reason for carefully
examining (1) the use cases, (2) their frequency, (3) any other attendant
benefits, (4) whether the proposed new syntax forecloses possibly useful
future extensions to the extent we can imagine them (such as "eating" some
valuable special character), (5) how easily it is parseable, (6) to what
extent it is consistent with existing syntactic constructs, (7) whether it
fills in some "gap" in the language (aka as "bringing parity"), (8) whether
it is unduly cryptic, (9) whether we think it will be relatively learnable
for those students of the language that choose to use it, and so on and so
forth.

With regard to Sebastian Malton's more recent post:

```
var a = {
    { b, c, d, e } = B
};
```

> I believe that this would be more consistent with the object
destructoring since it now uses the = sign and looks like it encapsulates a
descructure with {} which is like how the shorthand works

Yes, that proposal has already been made. It has certain advantages, as you
mention. It has the disadvantage that it does lend itself easily to picking
properties from one object into another existing object.

My current proposal for the above (at
https://github.com/rtm/js-pick-notation) is

```
var a = B.{b, c, d, e};
```

Bob



On Sat, Mar 17, 2018 at 3:41 AM, Sebastian Malton <sebastian at malton.name>
wrote:

> I disagree that this is something that doesn't happen often.
>
> var a = {
>     { b, c, d, e } = B
> };
>
> I believe that this would be more consistent with the object destructoring
> since it now uses the = sign and looks like it encapsulates a descructure
> with {} which is like how the shorthand works
>
> Sebastian Malton
>
>
>   Original Message
> From: jackalmage at gmail.com
> Sent: March 16, 2018 5:26 PM
> To: sebastian at malton.name
> Cc: es-discuss at mozilla.org
> Subject: Re: Expanding Object Shorthand
>
> On Fri, Mar 16, 2018 at 1:58 PM, Sebastian Malton <sebastian at malton.name>
> wrote:
> > Yes that is possible but what if you want to do the following?
> >
> > ```
> > var a = {
> >     b: B.b,
> >     c: B.c,
> >     d: B.d,
> >     e: B.e
> > };
> > ```
> >
> > Would it not be easier to do the following?
> >
> > ```
> > var a = {
> >     { b, c, d, e }: B
> > };
> > ```
>
> It's shorter to write, sure. But we can come up with special-purpose
> ways to shorten code all day.
>
> This proposal is not consistent with the existing shorthand syntax, or
> the object-destructuring syntax it also somewhat resembles. It's
> unique, while looking very similar to existing syntax, and for a
> relatively small case (extracting a subset of the properties of an
> object into another object, with the same key names).  That's usually
> not a recipe for success. :(
>
> ~TJ
> _______________________________________________
> 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/20180317/3fd13031/attachment.html>

I'm glad to see we are continuing to discuss this. It demonstrates some
degree of interest in the community for this feature, some degree of need.

With regard to Tab Adkins Jr.'s post:

> You can just write:

```
var d = {
  a,
  b,
  c: e.c
};
```

Yes, we know that, of course. You could also write `{a: a}`, but it was
decided that `{a}` was a nice shorthand. The question, as always, is how
commonly the situation arises (in my opinion: quite commonly), and how much
more compact the alternative is (in my opinion: reasonably more compact),
and/or what other benefits there might be (in this case, the benefit of not
mistyping one of the `c`'s).

>  and for a relatively small case (extracting a subset of the properties of an object into another object, with the same key names).  That's usually not a recipe for success. :(

There is no particular reason for believing that extracting a subset of the
properties of an object into another object is a smaller use case than
extracting the properties of an object into a variable. Even if it less
common than extracting into variables, one can argue for it on grounds of
feature parity.

>  It's shorter to write, sure. But we can come up with special-purpose ways to shorten code all day.

A classic fallacy, which if applied consistently would lead to rejecting
all proposals which are only or mainly syntax sugar. This ignores the fact
that a great number of ES6/7 features were/are in fact completely or at
least partially syntax sugar. Merely being syntax sugar does not constitute
a reason for rejecting something. It constitutes a reason for carefully
examining (1) the use cases, (2) their frequency, (3) any other attendant
benefits, (4) whether the proposed new syntax forecloses possibly useful
future extensions to the extent we can imagine them (such as "eating" some
valuable special character), (5) how easily it is parseable, (6) to what
extent it is consistent with existing syntactic constructs, (7) whether it
fills in some "gap" in the language (aka as "bringing parity"), (8) whether
it is unduly cryptic, (9) whether we think it will be relatively learnable
for those students of the language that choose to use it, and so on and so
forth.

With regard to Sebastian Malton's more recent post:

```
var a = {
    { b, c, d, e } = B
};
```

> I believe that this would be more consistent with the object destructoring since it now uses the = sign and looks like it encapsulates a destructure with `{}` which is like how the shorthand works

Yes, that proposal has already been made. It has certain advantages, as you
mention. It has the disadvantage that it does not lend itself easily to picking
properties from one object into another existing object.

My current proposal for the above (at
https://github.com/rtm/js-pick-notation) is

```
var a = B.{b, c, d, e};
```

Bob

I'm glad to see we are continuing to discuss this. It demonstrates some
degree of interest in the community for this feature, some degree of need.

With regard to Tab Adkins Jr.'s post:

> You can just write:

```
var d = {
  a,
  b,
  c: e.c
};
```

Yes, we know that, of course. You could also write `{a: a}`, but it was
decided that `{a}` was a nice shorthand. The question, as always, is how
commonly the situation arises (in my opinion: quite commonly), and how much
more compact the alternative is (in my opinion: reasonably more compact),
and/or what other benefits there might be (in this case, the benefit of not
mistyping one of the `c`'s).

>  and for a relatively small case (extracting a subset of the properties of an object into another object, with the same key names).  That's usually not a recipe for success. :(

There is no particular reason for believing that extracting a subset of the
properties of an object into another object is a smaller use case than
extracting the properties of an object into a variable. Even if it less
common than extracting into variables, one can argue for it on grounds of
feature parity.

>  It's shorter to write, sure. But we can come up with special-purpose ways to shorten code all day.

A classic fallacy, which if applied consistently would lead to rejecting
all proposals which are only or mainly syntax sugar. This ignores the fact
that a great number of ES6/7 features were/are in fact completely or at
least partially syntax sugar. Merely being syntax sugar does not constitute
a reason for rejecting something. It constitutes a reason for carefully
examining (1) the use cases, (2) their frequency, (3) any other attendant
benefits, (4) whether the proposed new syntax forecloses possibly useful
future extensions to the extent we can imagine them (such as "eating" some
valuable special character), (5) how easily it is parseable, (6) to what
extent it is consistent with existing syntactic constructs, (7) whether it
fills in some "gap" in the language (aka as "bringing parity"), (8) whether
it is unduly cryptic, (9) whether we think it will be relatively learnable
for those students of the language that choose to use it, and so on and so
forth.

With regard to Sebastian Malton's more recent post:

```
var a = {
    { b, c, d, e } = B
};
```

> I believe that this would be more consistent with the object destructoring since it now uses the = sign and looks like it encapsulates a destructure with `{}` which is like how the shorthand works

Yes, that proposal has already been made. It has certain advantages, as you
mention. It has the disadvantage that it does lend itself easily to picking
properties from one object into another existing object.

My current proposal for the above (at
https://github.com/rtm/js-pick-notation) is

```
var a = B.{b, c, d, e};
```

Bob

I'm glad to see we are continuing to discuss this. It demonstrates some
degree of interest in the community for this feature, some degree of need.

With regard to Tab Adkins Jr.'s post:

> You can just write:

```
var d = {
  a,
  b,
  c: e.c
};
```

Yes, we know that, of course. You could also write `{a: a}`, but it was
decided that `{a}` was a nice shorthand. The question, as always, is how
commonly the situation arises (in my opinion: quite commonly), and how much
more compact the alternative is (in my opinion: reasonably more compact),
and/or what other benefits there might be (in this case, the benefit of not
mistyping one of the `c`'s).

>  and for a relatively small case (extracting a subset of the properties

of an object into another object, with the same key names).  That's usually not
a recipe for success. :(

There is no particular reason for believing that extracting a subset of the
properties of an object into another object is a smaller use case than
extracting the properties of an object into a variable. Even if it less
common than extracting into variables, one can argue for it on grounds of
feature parity.

>  It's shorter to write, sure. But we can come up with special-purpose ways to shorten code all day.

A classic fallacy, which if applied consistently would lead to rejecting
all proposals which are only or mainly syntax sugar. This ignores the fact
that a great number of ES6/7 features were/are in fact completely or at
least partially syntax sugar. Merely being syntax sugar does not constitute
a reason for rejecting something. It constitutes a reason for carefully
examining (1) the use cases, (2) their frequency, (3) any other attendant
benefits, (4) whether the proposed new syntax forecloses possibly useful
future extensions to the extent we can imagine them (such as "eating" some
valuable special character), (5) how easily it is parseable, (6) to what
extent it is consistent with existing syntactic constructs, (7) whether it
fills in some "gap" in the language (aka as "bringing parity"), (8) whether
it is unduly cryptic, (9) whether we think it will be relatively learnable
for those students of the language that choose to use it, and so on and so
forth.

With regard to Sebastian Malton's more recent post:

```
var a = {
    { b, c, d, e } = B
};
```

> I believe that this would be more consistent with the object destructoring since it now uses the = sign and looks like it encapsulates a destructure with `{}` which is like how the shorthand works

Yes, that proposal has already been made. It has certain advantages, as you
mention. It has the disadvantage that it does lend itself easily to picking
properties from one object into another existing object.

My current proposal for the above (at
https://github.com/rtm/js-pick-notation) is

```
var a = B.{b, c, d, e};
```

Bob