Discuss
  • Expanding Object Shorthand

Expanding Object Shorthand

# Sebastian Malton (7 years ago)

An HTML attachment was scrubbed... URL: esdiscuss/attachments/20180316/f6d71459/attachment

# Tab Atkins Jr. (7 years ago)

On Fri, Mar 16, 2018 at 1:30 PM, Sebastian Malton <sebastian at malton.name> wrote:

Hello currently the following is a possible way to define an object.

var d = { a, b, c };

But this only works if the fields are already variables.

So if you wanted to select some fields from an object within you have to use temp variables, reference the field by name but without the temporary variables, or use some immediately called functions which is messy.

You can just use ordinary object-creation syntax. The syntax you're referencing is a shorthand, specifically for the limited, but common, case where you want to add a field with the same name as a variable. Like:

So I propose the following syntax:

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

Here d will have the fields [a, b, c] and the values are the variable a, variable b, and value e.c.

You can just write:

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

(Assuming that's what you meant, and not c.e for the last field's value.)

# Sebastian Malton (7 years ago)

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
};

Sebastian Malton

Original Message   From: jackalmage at gmail.com Sent: March 16, 2018 4:49 PM To: sebastian at malton.name Cc: es-discuss at mozilla.org Subject: Re: Expanding Object Shorthand

On Fri, Mar 16, 2018 at 1:30 PM, Sebastian Malton <sebastian at malton.name> wrote:

Hello currently the following is a possible way to define an object.

var d = { a, b, c };

But this only works if the fields are already variables.

So if you wanted to select some fields from an object within you have to use temp variables, reference the field by name but without the temporary variables, or use some immediately called functions which is messy.

You can just use ordinary object-creation syntax.  The syntax you're referencing is a shorthand, specifically for the limited, but common, case where you want to add a field with the same name as a variable. Like:

So I propose the following syntax:

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

Here d will have the fields [a, b, c] and the values are the variable a, variable b, and value e.c.

You can just write:

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

(Assuming that's what you meant, and not c.e for the last field's value.)

# Tab Atkins Jr. (7 years ago)

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. :(

# Sebastian Malton (7 years ago)

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. :(

# Bob Myers (7 years ago)

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 rtm/js-pick-notation) is

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

Bob

# Sebastian Malton (7 years ago)

An HTML attachment was scrubbed... URL: esdiscuss/attachments/20180317/8d312f83/attachment

# Oriol _ (7 years ago)

the last point doesn't haven't the same usability as my proposal since with mine multiple different objects can be selected from at a time

I believe that you could use Bob's proposal like this:

var obj = {...obj1.{prop1, prop2}, ...obj2.{prop3, prop4}};
# Michael Theriot (7 years ago)

Not up to speed with any pitfalls already discussed but for what it's worth I tried this at least a few times when destructuring landed and was disappointed it didn't work.

# Naveen Chawla (7 years ago)

Yes it seems like a natural combination of the destructuring and object shorthand features (the = version that is). Can anybody name the pitfalls or point to where they have been mentioned (if any have been)?

# Bob Myers (7 years ago)

Can anybody name the pitfalls or point to where they have been mentioned (if any have been)?

The pitfalls have been mentioned in various responses on related threads over the last year or two. I will take a stab at summarizing them, with my response/comments to each. Apologies in advance if I mischaracterized anyone's views or put words in their mouth..

1. The problem (picking properties into an object) is not common enough, or important enough, to worry about.

Maybe. Maybe not. For whatever reason, it's quite common in my own development (which is why I started thinking about this and continue flogging it). It may or may not be relevant that the problem has been asked on SO dozens of time, as well as frequently appearing on this mailing list. I don't doubt that some people may not need to do this very often, but is there any chance they're projecting their particular field or style of JS onto the rest of the world?

2. Even if picking is a common use case, it can be done without the new syntax.

Yes, that is the definition of "syntactic sugar". But merely being syntactic sugar is in and of itself not a sufficient reason for rejecting a proposal. Many proposals have been accepted over the years which are only or mainly syntax sugar. It boils down to a trade-off between how sweet the sugar is and how intense the cravings, which ends up being quite subjective.

*3. Even if you agree that new syntax is useful, the improvement in convenience does not justify the added language complexity. *

There are two sides to the equation here: the improvement in convenience, and the added language complexity. We need to consider both to assess this tradeoff. Whether one considers the improvement in convenience large or small, in this case the added language complexity can fairly be characterized as low in my opinion.

4. There are just too many dots and curly brackets in this syntax, and/or it's cryptic, or hard to read, or not obvious.

In an earlier version of the proposal, one would write { {a, b} = p }, which does seem to have a few too many { right next to each other. The current version is to say p.{a, b}. One might complain that it is easy to overlook the dot, I suppose. In terms of being "obvious", to me it seems quite obvious that if a.b means to take property b from a, then a.{b,c} would mean to take b and c.

Here are some other potential pitfalls, which to my knowledge have NOT been raised in connection with this proposal.

5. The proposed new syntax forecloses possibly useful future extensions. such as "eating" some valuable special character).

Since the only syntax change is allowing a left curly bracket after a dot, the proposed syntax "blocks" almost nothing in the future we can think of.

6. The proposed new syntax tricky to parse.

I'm not a parser guy, but the syntax changes are limited to detecting the { after the dot, and what comes then is exactly the same deconstructing construct that parsers already know how to parse.

7. The proposed new syntax incompatible with existing syntactic constructs.

I can't see how this could possible be the case. To the contrary, it is completely compatible with both dot notation (specifying properties to access or set after a dot), and deconstructing syntax.

-- Bob