That was mentioned in the V8 bug, so I'm aware. (I left that implied, thinking others would catch on.) -----
Isiah Meadows [email protected] 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> >>>>> 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 >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
