Suggestion: Destructuring object initializer.

[Alexander Jones]

The difference between `{...a, ...b}` and `Object.assign({}, a, b)` is the
same as the difference between `[a, b]` and `new Array(a, b)`. The latter
cases (correct me if I'm wrong) rely on dynamic lookup of names and
methods, whereas the former cases, as syntactical constructs, have
statically defined semantics. Not really sure if modern engines are able to
optimize around this yet. I'm sure someone here knows...

On 12 February 2018 at 13:45, Bob Myers <rtm at gol.com> wrote:

> 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.
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180212/cc73f9c2/attachment.html>