Re: What was said in this sentence?

On Wed, Feb 14, 2018 at 5:15 AM, Maxim Vaarwel wrote: >> >> "Whether the toString function can be applied successfully to a host object is implementation-dependent". What "implementation-dependent" > > What does this sentence say? What kind of implementation are we talking

Re: Suggestion: Destructuring object initializer.

On Wed, Feb 14, 2018 at 8:25 AM, Bob Myers wrote: > > > For example, I did a quick test comparing `[1, 2]` and `new Array(1, 2)` > and found that performance was identical, in spite of the claimed > inefficiency supposedly introduced by the need to look up `Array`. > > I'm curious

Re: Suggestion: Destructuring object initializer.

On Wed, Feb 14, 2018 at 8:25 AM, Bob Myers wrote: > > > With regard to the issue of the empty object inheriting a setter, my we're > really clutching at straws here. > > Really? I was simply informing you that `Object.assign({}, a, b)` is not equivalent to `{...a, ...b}`.

Re: Suggestion: Destructuring object initializer.

Actually, I did understand what he said. I didn't respond because it was obviously wrong. For example, I did a quick test comparing `[1, 2]` and `new Array(1, 2)` and found that performance was identical, in spite of the claimed inefficiency supposedly introduced by the need to look up `Array`.

Suggestion: Destructuring object initializer.

Bob, it's not clear that you understood what Alexander said about the lookup. Object.assign contains 2 names. 'Object' needs to be looked up in all the execution contexts chain, starting with the current execution context, until the global Object function is found. Then the 'assign' property must

What was said in this sentence?

> > "Whether the toString function can be applied successfully to a host > object is implementation-dependent". What "implementation-dependent" What does this sentence say? What kind of implementation are we talking about (The algorithm toString is concrete described)?

Re: Suggestion: Destructuring object initializer.

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

Re: Suggestion: Destructuring object initializer.

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.

Re: Suggestion: Destructuring object initializer.

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

Re: New operator

Please do some research before posting in the future. [1] https://esdiscuss.org/topic/or-equal-operator [2] https://esdiscuss.org/topic/proposing-a-conditional-assignment-or-equals-operator [3] https://esdiscuss.org/topic/new-assignment-operators-not-bit-wise-or [4]

New operator

Since the following is a decently common idiom I propose that we have a self referential version of it.Idiom:```jsmyVar = myVar || "default" ;``` New

Re: Suggestion: Destructuring object initializer.

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

Re: try/catch/else

Oops, you're right. I agree that `else` might not be the best keyword for this all things considering. On Tue, Feb 13, 2018, at 1:48 PM, T.J. Crowder wrote: > On Tue, Feb 13, 2018 at 12:37 PM, Alan Plum wrote: > > Not quite. > > You appear to have missed my message three minutes

Re: try/catch/else

On Tue, Feb 13, 2018 at 12:37 PM, Alan Plum wrote: > Not quite. You appear to have missed my message three minutes later, after I'd realized that: https://esdiscuss.org/topic/try-catch-else#content-16 -- T.J. Crowder ___ es-discuss

Re: try/catch/else

Not quite. If the `else` (or `nocatch`, whatever) block throws, it would bypass the `catch` block but still hit the `finally` block the same way an exception in the `catch` block would: * if `a` doesn't throw: a, b, d * if `a` throws: a, c, d * if `b` throws: a, b, d * if `a` and `c` throw: a, c,

Re: Suggestion: Destructuring object initializer.

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

Re: try/catch/else

On Tue, Feb 13, 2018 at 11:54 AM, T.J. Crowder wrote: > > Then > > * If `a` doesn't throw: a, b, d. > * If `a` throws: a, c, d. > * If `b` throws: a, b, c, d > * If `a` and `c` both throw: a, c, d > * If `b` and `c` both throw: a, b, c, d Gah, I forgot that you

Re: try/catch/else

On Tue, Feb 13, 2018 at 11:30 AM, Isiah Meadows wrote: > > If you did `else` before `catch`/`finally`, that'd solve your problem. ;-) > > The catch with `finally` (no pun intended) is this: does/should it > execute *before* or *after* else? Logically it makes sense

Re: try/catch/else

Going with python's semantics, finally should execute after else because else behaves analogous to catch. It's basically a "nocatch". On Tue, Feb 13, 2018, at 12:30 PM, Isiah Meadows wrote: > If you did `else` before `catch`/`finally`, that'd solve your problem. ;-) > > The catch with `finally`

Re: try/catch/else

If you did `else` before `catch`/`finally`, that'd solve your problem. ;-) The catch with `finally` (no pun intended) is this: does/should it execute *before* or *after* else? - Isiah Meadows m...@isiahmeadows.com Looking for web consulting? Or a new website? Send me an email and we can get

Re: Suggestion: Destructuring object initializer.

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*

Re: try/catch/else

Yikes, thanks for pointing that out. I guess this could be resolved by having a lower precedence for `catch/else` than `if/else` or by enforcing the sequence `try/else/catch` (as `try` without `catch` or `finally` is a syntax error). On Tue, Feb 13, 2018, at 2:06 AM, Waldemar Horwat wrote: >