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
about (The algorithm toS
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 how you did that
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}`.
_
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`.
I
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 b
>
> "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)?
___
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 diffe
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#issuecomme
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 be
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] https://esdiscuss.org/topic/pl
Since the following is a decently common idiom I propose that we have a self referential version of it.Idiom:```jsmyVar = myVar || "default" ;``` New Operator:```j
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
optimizatio
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 later, after I'
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 mailing list
es-disc
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, d
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
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 don't want the `else` block subject
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 `finally` would be after, so pu
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`
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
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
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:
> On
22 matches
Mail list logo