On Fri, Nov 17, 2017 at 1:50 PM, Michał Wadas <[email protected]> wrote:
> For me it boils down to "implementations which already don't follow spec > exactly won't be able to implement such new part of specification"... > > Dynamic code generation with access to existing scope (sloppy mode direct > eval) already puts strong constraints on spec-compliant implementation. Is > it even considered issue? > Technically, in order to accommodate CSP, the EcmaScript spec already allows an implementation to refuse to dynamically evaluate code via evaluators, i.e., the eval function, the various function constructors, and the import expression. > > On 17 Nov 2017 10:29 pm, "Isiah Meadows" <[email protected]> wrote: > >> Just FYI, I did talk a while back to one of the TC39 people previously >> about the viability of encoding at least the low-level microtask >> execution stuff into the spec, and they explained that for both >> practical and theological reasons, there really was no way of doing it >> that wouldn't require substantial changes to the HTML spec as well as >> issues with other embedding use cases. (Node would actually be the >> *least* affected in this area.) >> >> As for things like `setTimeout`/etc., ECMAScript is designed for *way* >> more than just browsers - it even runs on Arduino boards. Some >> runtimes that are geared towards embedded stuff deliberately don't >> even implement any form of dynamic evaluation, like Kinoma XS6 (ES6 >> runtime which also does not retain source code for >> `Function.prototype.toString` for ES-defined functions), and in those >> cases, you might only have a single core available in the hardware, >> making async timers, especially shorter ones, very unreliable and >> power-hungry to use. >> >> ----- >> >> Isiah Meadows >> [email protected] >> >> Looking for web consulting? Or a new website? >> Send me an email and we can get started. >> www.isiahmeadows.com >> >> >> On Thu, Nov 16, 2017 at 7:37 AM, Michał Wadas <[email protected]> >> wrote: >> > I wish we can have annex like "if host environment supports scheduling >> tasks >> > to run after certain time, it have to expose Promise.delay method >> working in >> > following way:". >> > >> > But it's unlikely to happen because TC39 opposes describing >> communication >> > with outside world in spec. >> > >> > On 16 Nov 2017 1:21 pm, "Naveen Chawla" <[email protected]> wrote: >> >> >> >> Wouldn't it be more useful to have an async `delay(milliseconds)` >> >> function, which simply takes a number (as an alternative to >> setTimeout), >> >> instead of having to pass in a function whose code is executed and >> then the >> >> code after it??? I have suggested that here before, but it happens to >> be a >> >> browser spec feature thing, not a core language thing (at least not >> yet) - >> >> since setTimeout itself is not yet in the core language, as far as I >> know >> >> >> >> On Thu, 16 Nov 2017 at 16:50 Eugene Melnikov >> >> <[email protected]> wrote: >> >>> >> >>> It’d be great to see native implementation of `waitFor` function. This >> >>> function is used a lot in test frameworks and sometimes it’s >> necessary to >> >>> wait something via polling. The syntax should be `await >> >>> waitFor(function/primitives, timeout)`. Once function in first >> argument >> >>> return anything except `false`, `null` or `undefined` next line of >> code will >> >>> be executed. Second argument means period of time in ms to run >> function from >> >>> first argument. Returned value of `waitFor` will be forwarded from >> executed >> >>> function. In case first argument if primitive the first argument will >> be >> >>> returned after delay specified in second argument. So it will be easy >> to >> >>> make simple delay `async waitFor(true, 1000)` instead of `await new >> >>> Promise(r => setTimeout(r, 1000))`. >> >>> _______________________________________________ >> >>> es-discuss mailing list >> >>> [email protected] >> >>> https://mail.mozilla.org/listinfo/es-discuss >> >> >> >> >> >> _______________________________________________ >> >> es-discuss mailing list >> >> [email protected] >> >> https://mail.mozilla.org/listinfo/es-discuss >> >> >> > >> > _______________________________________________ >> > es-discuss mailing list >> > [email protected] >> > https://mail.mozilla.org/listinfo/es-discuss >> > >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
