Suggestion: Destructuring object initializer.

Bob Myers rtm at gol.com
Mon Feb 12 13:45:42 UTC 2018


Thanks for reading my post down to the part that caught your attention.
Concerning this:

> engines can optimize for objects that are not referenced elsewhere by not
actually copying them, something harder to do with `Object.assign`.\*

I'm intrigued; please elaborate. I had thought that `{...a, ...b}` was 100%
identical in every way to `Object.assign({}, a, b)`.

> \* I don't know/believe if they do, but it's pretty easy to implement
with type info.

What kind of type info did you have in mind? Type info based on static
analysis currently performed and/or theoretically able to be performed by
engines against ECMAScript 20xx programs? In that case, why couldn't such
type inferencing be applied to optimizing the `Object.assign`-based
construct? Or do you mean type info from some kind of type annotation
system in the future?

Bob

On Sun, Feb 11, 2018 at 5:03 AM, Isiah Meadows <isiahmeadows at gmail.com>
wrote:

>
> Another common reaction is "big deal, saving a few characters or lines".
>> But more than one recent language feature also falls into this category of
>> mainly or purely sugar and brevity. For instance, property spread syntax is
>> pretty much just sugar for `Object.assign`, yet everyone seems to think
>> it's the best thing since sliced bread.
>>
>
> My understanding of this differs:
>
> - It was to bring feature parity with array spread destructuring.
> - The proposal included both merging and extracting.
> - It actually optimized for an exceptionally common case (React circles
> benefitted the most, but others did quite a bit, too), immutable update of
> record-like objects. In my experience, that scenario is *more* common than
> array spread (beyond rest parameters), and engines can optimize for objects
> that are not referenced elsewhere by not actually copying them, something
> harder to do with `Object.assign`.\*
> - You *could* implement it via `Object.assign`, but it chopped the number
> of characters down to less than half for most cases if you're not just
> merging. Most of these pick proposals aren't coming close.
>
> \* I don't know/believe if they do, but it's pretty easy to implement with
> type info.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180212/d7af24ad/attachment.html>


More information about the es-discuss mailing list