Ticket #111 (new feature)

Opened 2 years ago

Last modified 1 month ago

(Resolved) Shorthand object destructurings

Reported by: lth Assigned to: jeffdyer
Type: feature Priority: minor
Milestone: Component: Proposals
Version: Harmony Keywords: destructuring
Cc: brendan, jeffdyer, david-sarah@jacaranda.org

Description

I know Jeff has said "no new syntax" but I observe that when I use object destructurings, they are often of the sort where the field name and variable name are the same, because I'm just picking fields out of a structure in a single phrase:

  function cgIfStmt(ctx, { test: test,
                           alternate: alternate,
                           consequent: consequent }) {
     ...
  }

Might it be an idea to allow destructuring shorthands for this, a la SML:

  function cgIfStmt(ctx, { test, alternate, consequent }) {
     ...
  }

Syntactically, this is not ambiguous, from what I can tell.

There would be no problem with mixing both styles in a single destructurer:

  function cgIfStmt(ctx, { test, alternate: S1, consequent: S2 }) {
     ...
  }

Attachments

Change History

Changed 2 years ago by lth

Jeff says: in that case, in order to keep object constructors and destructurers compatible, perhaps one should allow the shorthand for construction as well, this might be useful for constructing subset or superset objects:

   f({x, y, z} = bigstruct)

Obviously makes no sense for type annotations, so we can't stretch the compatibility too far.

Changed 1 year ago by jeffdyer

  • owner set to jeffdyer
  • component changed from Proposals to RefImpl

Accepted at Yahoo! meeting. Changing to RI bug.

Changed 1 year ago by brendan

Not sure what "for construction as well" means -- the example

f({x, y, z} = bigstruct)

looks like destructuring assignment, as proposed here, and not construction via an object initialiser shorthand:

var o = {x, y, z}
assert(o.x === x)
assert(o.y === y)
assert(o.z === z)

assuming x, y, and z are bound in the scope chain.

Is this object initialiser shorthand proposed too? If so, I missed it at the Yahoo! f2f last summer. If not, then we are requiring more cover-grammar parsing followed by semantic checking, or bottom-up parsing -- something we have argued against elsewhere (e.g., any lambda syntax of the form x => x*x or (x, y) => a*x*x + b*y*y). (I'm not arguing for that lambda syntax, just asking about design rules and restrictions.)

/be

Changed 1 year ago by lth

You're right about the ambiguity. I think Jeff and I may have been misled by the desirability of shortening this object initializer:

   { x: x, y: y, z: z }

to this:

   { x, y, z }

(which is not ambiguous, I believe). Following the train of thought we get the more general pattern which now to mee looks like a combined destructure/structure, which is probably all wrong.

I would like to remove the shorthand construction proposals, to the extent they exist, from this ticket. A separate ticket could be opened for that.

This ticket is only about shorthand destructuring described in the Description, which (looking at the clutter in the ESC code) will certainly be handy.

Changed 1 year ago by jeffdyer

Agreed. Let's separate the two proposals. The destructuring shorthand covered by this ticket seems uncontroversial.

Jd

Changed 1 year ago by lth

  • priority changed from major to trivial
  • component changed from RefImpl to Spec
  • summary changed from Shorthand object destructurings to (Resolved) Shorthand object destructurings

Approved at the Jan 08 2008 meeting.

Changed 1 month ago by David-Sarah Hopwood

  • cc changed from brendan,jeffdyer to brendan, jeffdyer, david-sarah@jacaranda.org
  • component changed from Spec to Proposals
  • priority changed from trivial to minor
  • version changed from 4 to Harmony
  • milestone deleted
  • keywords set to destructuring
  • type changed from enhancement to feature

Proposal still relevant to ES-Harmony.

Note: See TracTickets for help on using tickets.