Yes, it's good note, that it can be "too public" and may be some one would
like to prevent external "intrusion" into it's "private state", but it can
be easily solved by the means of a wrappers, that wraps some private
``target`` and delegate to it only "safe calls", that will not
interrupt-it/canc
And that's why we're waiting on the next meeting to happen with notes
posted, so we can figure out what to do next. It's likely to get discussed,
especially considering the current situation and pressing need for it.
On Thu, Jan 12, 2017, 13:27 Jordan Harband wrote:
> The Cancellable Promises pr
Look up the "revealing constructor pattern". There's a reason why only the
creator can resolve a promise imperatively.
On Thu, Jan 12, 2017, 09:22 Igor Baklan wrote:
> Introduction of promise.return() and promise.throw() similar to
> generator.return() and generator.throw() can be helpful
>
> As
Okay, so it's a V8 bug. Filed it here:
https://bugs.chromium.org/p/v8/issues/detail?id=5834
On Thu, Jan 12, 2017, 03:03 T.J. Crowder
wrote:
> So to sum up, then, and circle back to Francisco Tolmasky's original
> question:
>
> * For ordinary objects, `Object.getOwnPropertyDescriptor` shouldn't
>
Okay. I see now. Lots of backtracking in the case of arrow functions and
ternary expressions vs type annotations.
On Thu, Jan 12, 2017, 00:45 Dmitry Soshnikov
wrote:
> The "early errors" are just parser errors which are enforced not by
> grammar rules, but by additional validation algorithms whi
The Cancellable Promises proposal itself is currently withdrawn, but don't
forget that all of the previous discussion on cancellation in promises led
to that proposal.
It would be shortsighted to pretend they don't exist, or that the spec
proposal won't matter forever to any other cancellation pro
Cancellable promises is dead. Please don't hijack this thread discussing
them.
Thanks,
.: Jan-Ivar :.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I'm mistaken about Step 1.e of [assignment evaluation][1], it's not
that we'd want to remove the IsIdentifierRef check, it's that we'd
want to make it "IsIdentifierRef is true or IsPropertyRef is true":
> e. If IsAnonymousFunctionDefinition(AssignmentExpression) is true and either
> IsIdentifierR
Introduction of promise.return() and promise.throw() similar to
generator.return() and generator.throw() can be helpful
Assuming analogy in tuples ([``function*``](https://
developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/
Statements/function*), [``yield``](https://developer.
mozilla.org/
So to sum up, then, and circle back to Francisco Tolmasky's original question:
* For ordinary objects, `Object.getOwnPropertyDescriptor` shouldn't
have side-effects because none of the ordinary operations it uses has
side effects.
* For exotic objects, it may well have side effects as a result of
10 matches
Mail list logo