Picking (deconstructing) properties into object literals

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Picking (deconstructing) properties into object literals

Bob Myers
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Picking (deconstructing) properties into object literals

Isiah Meadows-2
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
[hidden email]

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 <[hidden email]> 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
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Picking (deconstructing) properties into object literals

kai zhu
-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 <[hidden email]> 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
[hidden email]

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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Picking (deconstructing) properties into object literals

Ron Buckton

As a alternative, consider https://github.com/rbuckton/proposal-shorthand-improvements.

 

From: [hidden email]
Sent: Tuesday, August 22, 2017 9:45 PM
To: [hidden email]
Cc: [hidden email]
Subject: Re: Picking (deconstructing) properties into object literals

 

-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 <[hidden email]> 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
[hidden email]

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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Picking (deconstructing) properties into object literals

Marky Mark
In reply to this post by kai zhu

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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]

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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]

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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss