Suggestion: Destructuring object initializer.

[Isiah Meadows]

That was mentioned in the V8 bug, so I'm aware. (I left that implied,
thinking others would catch on.)
-----

Isiah Meadows
me at isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Wed, Feb 14, 2018 at 12:06 AM, Bob Myers <rtm at gol.com> wrote:
> Thanks for pointing that out, but remember that the `Object.assign`
> equivalent of `{...a, ...b}` is
>
> ```
> Object.assign({}, a, b)
> ```
>
> In other words, you are always starting off with an empty object, with no
> setters lying in wait to throw or do anything else. So the question is, are
> there any differences in terms of engine optimizability between the above
> and `{...a, ...b}`?
>
> and
> Bob
>
> On Wed, Feb 14, 2018 at 10:23 AM, Richard Gibson <richard.gibson at gmail.com>
> wrote:
>>
>> I'm unsure if `Object.assign(a, b)` and `{...a, ...b}` are equivalent in
>> terms of optimization opportunities, but I am certain that they are not
>> equivalent *in every regard* because Object.assign invokes setters but
>> object spread does not.
>>
>> cf. https://github.com/tc39/ecma262/pull/1069#issuecomment-361007960 :
>>
>> // throws
>> let a = Object.assign({ set x(v) { throw v } }, {x: 0});
>>
>> // copies properties
>> let b = { set x(v) { throw v }, ...{x: 0} };
>>
>>
>>
>> On Tue, Feb 13, 2018 at 10:12 PM, Bob Myers <rtm at gol.com> wrote:
>>>
>>> Thanks for engaging.
>>>
>>> This entire little sub-thread, and my question about what nuance I was
>>> missing, was related to one single item on your useful list of reasons why
>>> property spread was a good idea, namely your assertion that property spread
>>> permits engine optimizations which are different, or better, or easier, than
>>> those possible with `Object.assign`.
>>>
>>> I asked about this specifically because I had been under the impression
>>> that `{...a, ...b}` is semantically equivalent *in every regard* to
>>> `Object.assign(a, b)`. Then I was hoping that the issue you posted to the V8
>>> issue tracker would cast light on the difference, but could not see anything
>>> there that helped me understand it either. On the contrary, in your post as
>>> I read it you seem to be assuming/implying that the two cases are equivalent
>>> in terms of opportunities for optimization.
>>>
>>> I am perfectly willing to consider reasons for bringing in property
>>> spreads such as "parity" or "brevity". It's a separate discussion as to
>>> whether or not those other criteria do or do not apply, or to what degree
>>> they might apply, to property picking. First, I just want to understand the
>>> point about engine optimization, because if that is actually the case it
>>> would seem to be a very compelling argument. The simple version of the
>>> question is, are there or are there not engine optimizations specifically
>>> made possibly by property spread syntax which would not be possible with
>>> `Object.assign`, and if so what are they?
>>>
>>> Bob
>>>
>>>
>>> On Wed, Feb 14, 2018 at 12:44 AM, Isiah Meadows <isiahmeadows at gmail.com>
>>> wrote:
>>>>
>>>> The nuance is that it is far more concise, making it more useful for
>>>> frequent immutable updates, and it brings consistency with array spread (it
>>>> was briefly considered to make a symbol for customizing object spread, but
>>>> it was ultimately rejected for reasons I can't remember). Also, the
>>>> optimizations would be much less speculative (you could perform them at the
>>>> baseline level for object spread with some effort, unlike with
>>>> `Object.assign`).
>>>>
>>>>
>>>> On Tue, Feb 13, 2018, 07:26 Bob Myers <rtm at gol.com> wrote:
>>>>>
>>>>> Cool. I don't claim to fully understand this, but as I read your issue,
>>>>> it seems the optimization could/would apply to either spread properties OR
>>>>> `Object.assign` case. If that's true, then there's nothing specially
>>>>> optimizable about spread properties, in which case that particular point
>>>>> would NOT have been a reason to support its adoption. Or is there some
>>>>> nuance I'm missing?
>>>>>
>>>>> On Tue, Feb 13, 2018 at 4:58 PM, Isiah Meadows <isiahmeadows at gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> BTW, regarding engine optimizability of those, I've filed a couple V8
>>>>>> bugs:
>>>>>>
>>>>>> - https://bugs.chromium.org/p/v8/issues/detail?id=7435 (object spread
>>>>>> + `Object.assign`)
>>>>>> - https://bugs.chromium.org/p/v8/issues/detail?id=7436 (array spread +
>>>>>> `Array.prototype.concat`)
>>>>>>
>>>>>> There are things engines *could* do that they *aren't currently
>>>>>> doing*. Part of why I proposed V8 take a look at this is because it
>>>>>> has one of the more flexible IC systems out of all the engines (they
>>>>>> can lower `Array.prototype.map` to a simple loop for dense arrays even
>>>>>> though a simple `delete array[index]` within the loop breaks the
>>>>>> assumption - this is *exceptionally* difficult to implement with the
>>>>>> ability to deoptimize).
>>>>>> -----
>>>>>>
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>