domenic at domenicdenicola.com (2014-01-30T15:49:44.682Z)
It seems like this is largely a matter of personal aesthetics ("feels dirty," "hacky," etc.) but nothing is wrong or even hard functionally. Furthermore given the prevalence of code out there that uses such "hacks" without compunction, it seems that your aesthetics are not shared by most.
Maybe the easiest path toward resolving this, um, problem?, is simply adjusting your preferences to recognize this kind of code for the beautiful code it is.
It seems like this is largely a matter of personal aesthetics ("feels dirty," "hacky," etc.) but nothing is wrong or even hard functionally. Furthermore given the prevalence of code out there that uses such "hacks" without compunction, it seems that your aesthetics are not shared by most. Maybe the easiest path toward resolving this, um, problem?, is simply adjusting your preferences to recognize this kind of code for the beautiful code it is. On Jan 24, 2014, at 4:07, "Bradley Meck" <bradley.meck at gmail.com<mailto:bradley.meck at gmail.com>> wrote: Taking note with async polyfills and syntax for a minute. I spent a fair amount of time actually writing the spec of my intent/goal after getting some thought and working things through in my head (varies slightly from old 2011 await): https://gist.github.com/bmeck/674e21f40fe6e9ce6304#file-close-but-no-cigar-sweet-js-L6 I can get really close with sweet.js (see gist), but as such I still have to use new when invoking the generator function which feels dirty in my mind. Perhaps if I did some crazy code transforms to test if the generator function was using await it would work. That would require me to wrap it similar to how task.js and all the other libraries IRC bombarded me with. I think it very strange that they all: 1. make a promise that will be returned (finalPromise) 2. call the generator and hook it up to the promise 3. don't appear to have a clean way to make the generator continue without resolving finalPromise and without forcing the generator to completion * bluebird's Promise.coroutine comes closeish but still needs to run the generator to completion It seems that every approach I am taking gets me slightly closer, but none are a clean way for a generator to iterate itself without some hacky argument passing and wrapping. PS. Sorry about the horrifying sweet.js macro, but it is functional enough in Chrome with experimental JS from what I tried out. On Fri, Jan 24, 2014 at 2:18 AM, David Herman <dherman at mozilla.com<mailto:dherman at mozilla.com>> wrote: On Jan 23, 2014, at 4:49 PM, Brendan Eich <brendan at mozilla.com<mailto:brendan at mozilla.com>> wrote: > Domenic Denicola wrote: >> Task.js is still on "JavaScript1.8," and is not ES6-compatible. It won't work with modern browsers, or with Regenerator. > > Fork and fix, should be easy. I expect a PR would be accepted in due course. SpiderMonkey seems to have ES6 generator support somewhat there (thanks to Andy Wingo), should be all there soon enough. Working on it lately, actually. And using regenerator for the tests (\o/)! Also drastically simplifying the library since the customizable scheduler stuff, while kind of neat, is probably less compelling than a minimal library. Down to under 150 lines, unminified with comments, and still shrinking... Dave _______________________________________________ es-discuss mailing list es-discuss at mozilla.org<mailto:es-discuss at mozilla.org> https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss at mozilla.org<mailto:es-discuss at mozilla.org> https://mail.mozilla.org/listinfo/es-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140124/076b234d/attachment-0001.html>