My apologies if I was not clear. What I am asking is just

*Please explain the potential for engine optimizations offered by property
spread syntax `{...a, ...b}` which is not available or as easy with the
alternative `Object.assign({}, a, b)`.*

Kindly note that there is no need for purposes of this thread to comment on:

1. Any optimizations related to not needing to look up the `Object` symbol
or its `assign` method, since the engines have apparently already figured
out and implemented that optimization, and therefore in and of itself that
optimization does not constitute an argument in favor of property spread
syntax, which is the context of this discussion.

2. Any behaviors caused by non-standard characteristics of `{}` which is
used as the first argument to `Object.assign`, such as setters on
`Object.prototype`, since not only should the engines be able to exclude
such cases from its optimizations, but in any case any such issues could be
removed from consideration by using as the alternative
`Object.assign(Object.create(null), a, b)`, and therefore this point also
does not affect the point of the discussion, which is whether or not
property spread syntax offers unique opportunities for optimization not
heretofore present.

3. Other aspects of property spread syntax which supported its adoption, as
valid or convincing as such arguments might be, since those can and will be
discussed separately; this particular discussion is about whether or not,
and if so in what matter, property spread syntax offers NEW optimization
opportunities to the engines.]]

Bob

On Wed, Feb 14, 2018 at 2:37 PM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:

> On Wed, Feb 14, 2018 at 6:25 AM, Bob Myers <r...@gol.com> wrote:
> > Actually, I did understand what he said. I didn't respond because
> > it was obviously wrong.
>
> It was obviously right. In [the message that he replied to][1] you said:
>
> > I had thought that `{...a, ...b}` was 100% identical in every way
> > to `Object.assign({}, a, b)`.
>
> You didn't say "Identical in effect if you disregard potential performance
> optimizations which the engines I checked don't seem to do based on a quick
> test I did." You said "100% identical in every way." To then throw
> "obviously wrong" at the man when he points out how they aren't "100%
> identical in every way" is -- to put it mildly -- not polite discourse.
>
> There are at least two differences:
>
> 1. As Alexander Jones quite correctly pointed out, `Object.assign({}, a,
> b)` requires looking up `Object` in the scope chain and then requires
> looking up `assign` on the object it finds. Engines are **required** to do
> that or behave as though they did. They can optimize the heck out of it (as
> a non-engine-implementer I can easily think of ways to optimize for the
> overwhelmingly-common case where those are their default values), but
> that's a difference. If you shadow or reassign `Object`, or (yikes) modify
> or delete `Object.assign`, spread still works; `Object.assign` doesn't.
>
> 2. `Object.assign({}, a, b)` necessarily involves a function call; `{...a,
> ...b}` doesn't. Again, engines are **required** to perform a function call,
> or behave such that they did. And again, in my naïveté I can think of a way
> to optimize for the overwhelmingly-common-case there, but that's
> optimization. It's another difference.
>
> Those differences may or may not translate into *performance* differences
> once spread support matures (last I checked, a couple of months ago, I was
> surprised to find the fairly-new spread was markedly slower than
> `Object.assign`, but presumably that will change as the new stuff beds in).
> But they *are* differences.
>
> So no, `Object.assign({}, a, b)` and `{...a, ...b}` are not 100% identical
> in every way.
>
> -- T.J. Crowder
>
> [1]: https://esdiscuss.org/topic/suggestion-destructuring-object-
> initializer#content-13
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to