Re: Introspect bind function targets
Given that you can also do `const c = (...args) => proto.call(null,
...args);`, and `Function.isSameTarget(a, c)` would presumably be `false`,
can you elaborate more on the use case for this?
On Mon, Feb 4, 2019 at 9:38 AM Sultan wrote:
> A way to determine if two bound functions reference the same target
> function.
>
> For example:
>
> function proto () {}
>
> const a = proto.bind(null, 1)
> const b = proto.bind(null, 2)
>
> console.assert(Function.isSameTarget(a, b))
> ___
> 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
Re: NumberFormat maxSignificantDigits Limit
There is precedence for using numbers around 20 for significant digit cutoffs in the spec. For example, if you look at how number tokens are parsed in the spec (ยง11.8.3.1), the implementation has the option to ignore significant digits after the 20th. That's not a bug; we did that intentionally in the early days of ECMAScript as a compromise between always requiring exact precision and cutting off after the 17th digit, which would get a significant fraction of values wrong. Waldemar ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Introspect bind function targets
A way to determine if two bound functions reference the same target
function.
For example:
function proto () {}
const a = proto.bind(null, 1)
const b = proto.bind(null, 2)
console.assert(Function.isSameTarget(a, b))
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: returning non-Promise values from async functions and running them synchronously (or Promise.sync() idea)
Unfortunately, turning async code (which often has components that execute in a different thread or process) back into in sync code is really, really hard. What semantics would you give to this `Promise.sync()`? Can other code be executed by the main thread while you're waiting for your promise to be fulfilled? * If the answer is "no", you need to also block the entire DOM and CSS engines (both of which can call back into JavaScript) for this to work. Or, if you're in Node, all your I/O and all your ongoing callbacks. Needless to say, your users aren't going to be happy. * If the answer is "yes", you are breaking the run-to-completion guarantee of JavaScript. You may have events that are processed in the middle of apparently synchronous execution because there's a `Promise.sync()` hidden somewhere. That's going to break a lot of things. For what it's worth, Firefox used to have an equivalent of `Promise.sync()` for use in privileged code (i.e. the UI and extensions). Experience shows that it caused insane amounts of bugs. Cheers, David P.S.: Yes, there are ways around this, if you're willing to write/use a CPS transpiler. I've written one years ago. The results were really powerful, but also really messy. I don't suggest heading in this direction. On 04/02/2019 00:39, #!/JoePea wrote: > I often find myself enjoying async functions until the time comes when I > don't want to await anything, and I want the call stack to be sync (i.e. > I don't want to defer if I don't have to). > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
