Intent to Ship: Object rest/spread properties

[Sathya Gunasekaran]

Contact Emails:
gsa...@chromium.org

Spec:
https://tc39.github.io/proposal-object-rest-spread/

Summary:
ECMAScript 6 introduced rest elements for array destructuring
assignment and spread elements for array literals. This proposal
introduces analogous rest properties for object destructuring
assignment and spread properties for object literals.

Rest properties collect the remaining own enumerable property keys
that are not already picked off by the destructuring pattern. Those
keys and their values are copied onto a new object.

Spread properties in object initializers copies own enumerable
properties from a provided object onto the newly created object.

Interoperability and Compatibility Risk:
This is a stage 3 feature.

This new language feature allows syntax that was previously a
SyntaxError, so compatibility risk is low.

Webkit has shipped this in Safari Tech Preview Release 27. Firefox and
Edge have not implemented this yet.

Tracking bug:
https://bugs.chromium.org/p/v8/issues/detail?id=5549

Chrome status entry:
https://www.chromestatus.com/feature/5657004848709632

[Adam Klein]

Are there test262 tests for this feature (do we pass them?)?

[Sathya Gunasekaran]

On Thu, Apr 20, 2017 at 12:31 PM, Adam Klein <ad...@chromium.org> wrote:
> Are there test262 tests for this feature (do we pass them?)?
>

Yes. The tests were added here --
https://github.com/tc39/test262/issues/865

The latest test262 roll has pulled these tests into our harness --
https://chromium-review.googlesource.com/c/471546/

V8 passes all the tests.

[Adam Klein]

Thanks, LGTM to ship!

[PhistucK]

Is it fine to ship it as it is a stage 3 proposal at the moment?

See tc39/proposals.

☆PhistucK

Thanks, LGTM to ship!

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[PhistucK]

Cool, thank you and sorry!

☆PhistucK

On Thu, Apr 27, 2017 at 6:20 PM, Jeffrey Yasskin <jyas...@chromium.org> wrote:

Stage 3 is exactly the stage at which implementations are supposed to ship: https://tc39.github.io/process-document/, in particular the entrance criteria for stage 4 require that 2 implementations have shipped.

[PhistucK]

Indeed, not the appropriate mailing list.

(I can attest that I have been using object spread for almost a year. It is mostly useful in a React and Redux setup, but probably not only. jQuery has its shallow and not shallow extend method for a reason. I have been using JavaScript extensively since around 2001, so not a novice by definition.)

☆PhistucK

On Sun, Apr 30, 2017 at 6:02 AM, kai zhu <kaiz...@gmail.com> wrote:

i apologize if this is not the most appropriate mailing list, but i can’t help but express my frustration at the chaos in frontend-world caused by over-abuse of all the new es language features being introduced.  this rest/spread syntax is of particularly questionable use, and its likeliness to introduce bugs far outweighs its convenience, not to mention degrading overall code-readability and logic-reasoning for anyone besides the original coder.

i sometimes wonder what the hell the tc39 committee members were thinking when they created the es6 language-spec.  are any of them seriously frontend-engineers?  do they realize almost none of es6 language features addresses practical frontend painpoints, and mostly exacerbates them, especially in the hands of novice javascript programmers (who are typically the only ones businesses outside of silicon-valley can afford to hire)?

-kai

[looro...@gmail.com]

I am a student who has been programming in JS for roughly 2 years, though I write more code in C++ then in JS, only do some front-end stuffs as a hobby. Does that count as a novice in your definition?

Personally, I find some new JS syntax like class, variadic argument and default parameter not only make the code more readable but also more optimizable by JS engine. I can finally write JS code in more "C++ like" way!

I do agree some new JS syntax are not very helpful for me. But then again, these new JS syntax are opt-in, meaning I can still use old syntax as usual and old code should continue to work.

Tc39, like any other programming language specification committees, is very serious about backward compatibility, otherwise some old (often misused, hard to optimize, roots of many bugs) syntax like "with" and "eval" would have been removed long time ago. (I would love to see <iostream> to get removed from C++, but alas, backward compatibility).

Toolings for ES6 and onwards shouldn't be a big issue. Many tools and JS engines itself implement new JS features and iterate quickly before the proposal is even finalized.

I think the main issue most people face will be lack of interest to try/learn new things and adapt, which IMHO is one of the most important skill in general programming.

Maybe https://github.com/tc39/ecma262/issues is a better place for such discussion?

- Rong Jie

On Sunday, April 30, 2017 at 2:40:57 PM UTC+8, kai zhu wrote:

no, not everyone with stakes in frontend-development is as smart as you or the other blink-devs here, and you people setting standards really should care about these lesser mortals.  i just wish some of you can look out your ivory towers and see the misery and disenfranchisement of tech companies around the world unable to ship frontend-products these days, due to the chaos and confusion over es6 and its toolings, and how it undid many of their “solved” frontend painpoints.

-kai