Re: Queue Feature Request

Thnx Filip. Could you elaborate on how it works, or point me to the relevant code? If you have a robust solution that trumps V8's, I can take it to the V8 contributor mailing list and try to implement it. Zach Boldyga Scalabull | Founder 1 (866) 846-8771 x 101 On Sun, Feb 26, 2017 at 5:25 AM,

Re: Enable async/await to work on functions that don't just return promises.

Codefined, just out of curiousity, do you have anything to do with this proposal that got announced today ? Or is it just a coincidence? :) ​ On Sun, Feb 26, 2017 at 3:07 PM Dean Tribble wrote: > Should `callee()` be asynchronous here? To my mind, no,

Re: Enable async/await to work on functions that don't just return promises.

> > Should `callee()` be asynchronous here? To my mind, no, it shouldn't. > Every single line here is synchronous, so the function itself should surely > be synchronous. Shouldn't functions that may not have `await` in them, but > instead that are actually asynchronous and hence use the `async re

Re: Do settled promise chain handlers fire in the same turn?

On Sun, Feb 26, 2017 at 7:49 PM, /#!/JoePea wrote: > > Thanks T.J., that explains it well. Glad that helped! > I asked because I'm working with synchronous tests, so I'm wondering > how to resolve ES6 Promises with fake network data synchronously, > and fire all the handlers synchronously, all w

Re: Feedback on Iterable Numbers Proposal?

On Sun, Feb 26, 2017 at 7:40 PM, kdex wrote: > On that note, it might make more sense to add range literals. > That was my thought as well -- or at least, ranges if not range literals. (A simple `Range` is trivial to implement, but I'd rather see something ubiquitous.) I don't see any active, in

Re: Do settled promise chain handlers fire in the same turn?

Thanks T.J., that explains it well. I asked because I'm working with synchronous tests, so I'm wondering how to resolve ES6 Promises with fake network data synchronously, and fire all the handlers synchronously, all within the synchronous test function. Any recommendation on that? */#!/*JoePea

Re: Feedback on Iterable Numbers Proposal?

A Range type seems to me clearer, more powerful, and less magical. Even without syntax, the clarity seems better: //for-of syntaxfor (const i of Range.upto(5)){ //do something with i } for(const i of Range.from(3, 15)){ //do something with i } Whether Range's are a class or it's just a se

Re: Feedback on Iterable Numbers Proposal?

On that note, it might make more sense to add range literals. On Sunday, February 26, 2017 8:39:28 PM CET kdex wrote: > I like this proposal a lot! > > The only thing I'd like to remark is that I can see people getting confused > about the exact range that you're iterating over. > Some languages

Re: Feedback on Iterable Numbers Proposal?

On that note, it might make more sense to add range literals. On Sunday, February 26, 2017 8:39:28 PM CET kdex wrote: > I like this proposal a lot! > > The only thing I'd like to remark is that I can see people getting confused > about the exact range that you're iterating over. > Some languages

Re: Feedback on Iterable Numbers Proposal?

I like this proposal a lot! The only thing I'd like to remark is that I can see people getting confused about the exact range that you're iterating over. Some languages provide constructs to include/exclude the last element in the range. On Sunday, February 26, 2017 8:00:39 PM CET John Henry wr

Feedback on Iterable Numbers Proposal?

Howdy!, My name is John and I have a (hopefully non-contentious) addition for the ECMA Script Language described here: https://github.com/johnhenry/make-numbers-iterable. I wonder if there are good folks out there willing to give me feedback? I also wonder if someone might be willing to champion t

Re: Enable async/await to work on functions that don't just return promises.

A very interesting read indeed Alexander!  Gave me a new example to give when people ask what the worst code I'd ever seen was: Promise DoSomething(Promise cmd) { return cmd.WhenResolved( s => { if (s == "...") { return DoSomethingElse(...).WhenResolved( v => { return ...; }, e => { Log(e); thro

Re: Enable async/await to work on functions that don't just return promises.

Required reading for anyone who wants to be so... opinionated ;) http://joeduffyblog.com/2015/11/19/asynchronous-everything/ On Sun, 26 Feb 2017 at 16:35, Florian Bösch wrote: > On Sun, Feb 26, 2017 at 5:30 PM, Codefined > wrote: > > I'll be interested to see what you guys consider the > advan

Re: Enable async/await to work on functions that don't just return promises.

You seem to be feel incredibly jaded about nearly everything posted here.   Perhaps if you suggested your own proposal that showed the clear advantages of co-routines as you see it, then you might solve some of the issues instead of just whining about it. I assume that every single Javascript de

Re: Enable async/await to work on functions that don't just return promises.

On Sun, Feb 26, 2017 at 5:30 PM, Codefined wrote: > I'll be interested to see what you guys consider the > advantages/disadvantages of this method, which I hope to be "the middle > between two ends" on whether to go fully into promises or fully into > co-routines. Neither of which are in my opin

Re: Enable async/await to work on functions that don't just return promises.

Thank-you guys for the excellent problems with the previous idea, to attempt to fix as many of them as I can, here is an alteration to the proposal: You have two types of functions, asynchronous and synchronous functions.  To distinguish between them, an asynchronous function has the keyword of

Re: Enable async/await to work on functions that don't just return promises.

await/async are de-facto co-routines. await/async will infect all code by necessity of software engineering. At which point they're actual co-routines, implemented badly, without a proper API. On Sun, Feb 26, 2017 at 3:26 PM, Jerald Cohen wrote: > Florian, > > You sure you're not just adding mor

Re: Enable async/await to work on functions that don't just return promises.

Florian, You sure you're not just adding more complexities to a language with features that were _meant_ to remove such complexity? Codefined's solution to me seems to be the one with the least amount of added techniques in order to learn. Although I understand how co-rountines are awesome, they

Re: Enable async/await to work on functions that don't just return promises.

On Sun, Feb 26, 2017 at 2:51 PM, Codefined wrote: > What I feel we need is some way of making an asynchronous function > "appear" to be synchronous. > That's what co-routines are. Best practices for co-routines is usually to have some sort of API to spawn them (like new Routine(somefunction)), to

Re: Enable async/await to work on functions that don't just return promises.

Ah, that would indeed make sense.  What I feel we need is some way of making an asynchronous function "appear" to be synchronous.  Actually that's sort of what I expected async/await to do, but that only seems to affect where it's called, as opposed to the function itself.___

Re: Standardize global `setTimeout`/etc.?

What I meant, is that I don't think it'd be wise to duplicate DOM standards on the ES side or, even worse, create specification incompatibilities. Timers are just the top of the iceberg, IMO On Sun, Feb 26, 2017 at 1:31 PM, T.J. Crowder < tj.crow...@farsightsoftware.com> wrote: > On Sun, Feb 26,

Re: Standardize global `setTimeout`/etc.?

On Sun, Feb 26, 2017 at 1:20 PM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > These are standard already: > https://www.w3.org/TR/2011/WD-html5-20110525/timers.html#timers That's only for browsers. As far as I know, there's no standard for the broader picture Isiah was talking about.

Re: Queue Feature Request

Our queue optimizations are not JIT based. -Filip > On Feb 25, 2017, at 20:38, Zach Boldyga wrote: > > So both the more modern versions of V8 and Webkit's JIT both make automatic, > background attempts to amortize Array's deque-type operations. I wonder why > both teams decided to make that

Re: Enable async/await to work on functions that don't just return promises.

On Sun, Feb 26, 2017 at 2:17 PM, Codefined wrote: > Because `d()` is no longer an asynchronous function, you can call it like > normal, surely? > Only async functions can await. Only await pauses execution to wait on async. ___ es-discuss mailing list

Re: Standardize global `setTimeout`/etc.?

These are standard already: https://www.w3.org/TR/2011/WD-html5-20110525/timers.html#timers It's rather a matter of "what in the W3C global scope should be available on ECMAScript specifications too" ? 'cause timers are not the only thing that comes handy. Native URLSearchParams and URL are also

Re: Enable async/await to work on functions that don't just return promises.

Hey Florian, Why do we even need to do that? async function someAsync() { something(() => { return "hello"; }); } let d = function() { return await someAsync(); } let c = function() { return d(); } Because `d()` is no longer an asynchronous function, you can call it like normal, surely? On 26/

Re: Enable async/await to work on functions that don't just return promises.

On Sun, Feb 26, 2017 at 2:08 PM, Jerald Cohen wrote: > (although, at the moment, I fail to see why one can't just use a normal > "return"). > You're probably unaware of this, but there is a fixation in this community, and many adjacent ones, that if you sprinkle syntax magic dust atop co-routine

Re: Enable async/await to work on functions that don't just return promises.

To illustrate that, I went to Github , I looked for repositories that match "await" and are JS (471 repositories). The first few hits where microframeworks with minimal code or language parser, but the

Re: Enable async/await to work on functions that don't just return promises.

I actually really like this idea. It reminds me of the C# syntax to try to accomplish the same thing. Although under the bonnet C# uses "tasks", which appear to be their form of promises, the surface code does look very similar, take for example: public async Task MyMethodAsync(){ Task longR

Re: Enable async/await to work on functions that don't just return promises.

It would be nice if there even was an argument, but there isn't. There isn't because async/await naturally devolves into implicit coroutines, so any argument would be moot. To illustrate, suppose you have these 4 functions: let a = function(){ return b(); } let b = function(){ return c(); }

Re: Enable async/await to work on functions that don't just return promises.

Florian, you shouldn't pass the argument of explicit vs implicit coroutines off as being so simple. There are many compelling arguments for both! Please Google them! On Sun, 26 Feb 2017 at 00:01, Florian Bösch wrote: > On Sat, Feb 25, 2017 at 11:55 PM, Codefined > wrote: > > This seems to be s

Re: Enable async/await to work on functions that don't just return promises.

Hello Isiah, I'm not sure you understand my point on why this is important.  Although if you understand all the concepts used here it's logical, it's very intimidating to a person newer to Javascript.  This could be especially true in a framework like Node.JS, where you can run into a situation