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). ----- Isiah Meadows m...@isiahmeadows.com Looking for web consulting? Or a new website? Send me an email and we can get started. www.isiahmeadows.com On Mon, Feb 12, 2018 at 5:03 PM, Alexander Jones <a...@weej.com> wrote: > 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 <r...@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 <isiahmead...@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@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
