Discuss
  • Suggested Enhancement to ecmascript

Suggested Enhancement to ecmascript

# Matthew Tedder (7 years ago)

wait for ( condition );

Stop executing statements until the condition evaluates to true. To implement this, freeze the instance of the function in, add a hook to each variable in the condition so that when its value is written to, the condition is re-evaluated.

This will greatly increase the clarity and reduce coding needed for operations with many asynchronous calls and any with callbacks using arrow functions.. E.g.,

let a = false; let b = 5; let c = 'oranges'; doSomethenWhenever( () => { a = true; }

doAnotherThingWhenever( () => { b = 16; }

DoYetAnotherThing( () => { c = 'apples'; }

wait for ( a && b > 10 && c !== 'oranges' );

console.log('Conditions are met!');

# Michał Wadas (7 years ago)

What's wrong with async functions and await Promise.all([a, b, c]) ?

# Pranay Prakash (7 years ago)

I agree, Promises easily allow you to do this. Even if you wanted to 'wait' on an event, you can either.

  1. Use EventEmitter and simply have an 'on' handler
  2. Create a promise and pass the resolve function to whatever js doing the work, and await on the promise itself

You can also wrap an event emitter callback with a promise, oe use something like RxJS for Observables. So many possibilities.

# Sebastian Malton (7 years ago)

An HTML attachment was scrubbed... URL: esdiscuss/attachments/20180511/61de6ed5/attachment

# Isiah Meadows (7 years ago)

About the only broadly useful reasons to want a "wait for" mechanism are with reactive cells (most reactive libraries don't even have these) and atomics (which already have Atomics.wait).

But short that, I genuinely don't see the point.

As for event emitters, they're dead simple to implement. 1 But on the same token, I'm not convinced it's either 1. something that actually belongs in the spec instead of userland, or even 2. something that should be used in most new code. (Highly state machine-based code is the exception, not the norm here.) I'd definitely invite you to check out Kris Kowal's "General Theory of Reactivity" 2 - it's very highly informative.

Isiah Meadows me at isiahmeadows.com, www.isiahmeadows.com

# Alex Vincent (7 years ago)

---------- Forwarded message ---------- From: Sebastian Malton <sebastian at malton.name> To: Pranay Prakash <pranay.gp at gmail.com>, "Michał Wadas" < michalwadas at gmail.com> Cc: Matthew Tedder <matthew.tedder at hyperconversal.com>, es-discuss < es-discuss at mozilla.org> Bcc: Date: Fri, 11 May 2018 18:25:08 -0400 Subject: Re: Suggested Enhancement to ecmascript What would be nice is if we could have a good way of watching a variable. Maybe a built in way to create a custom event emitter.

Watching a variable directly might not be available. That said, if you're willing to wrap the variable in an object, it's very doable via property descriptors. They allow you to implement getters and setters which refer to another property, either publicly exposed or in a closure.

Keep in mind private variables don't really exist - yet - in ECMAScript. They can be achieved right now through a JavaScript Proxy, but that's pretty heavy-weight, and tricky to get right. I've been working on a proxy-based library to do exactly that, named es-membrane... and I'm still looking for help for the times when I'm just too busy.