Add new function waitFor

Mark Miller erights at gmail.com
Fri Nov 17 23:54:59 UTC 2017


On Fri, Nov 17, 2017 at 1:50 PM, Michał Wadas <michalwadas at gmail.com> 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" <isiahmeadows at gmail.com> 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
>> me at isiahmeadows.com
>>
>> 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 <michalwadas at gmail.com>
>> 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" <naveen.chwl at gmail.com> 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
>> >> <melnikaite.melnikaite at gmail.com> 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
>> >>> es-discuss at mozilla.org
>> >>> https://mail.mozilla.org/listinfo/es-discuss
>> >>
>> >>
>> >> _______________________________________________
>> >> es-discuss mailing list
>> >> es-discuss at mozilla.org
>> >> https://mail.mozilla.org/listinfo/es-discuss
>> >>
>> >
>> > _______________________________________________
>> > es-discuss mailing list
>> > es-discuss at mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
  Cheers,
  --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171117/1773d527/attachment-0001.html>


More information about the es-discuss mailing list