Fwd: Reason why generators do not have references to themselves?

Bradley Meck bradley.meck at gmail.com
Fri Jan 24 08:02:03 PST 2014

Perhaps, but I am still a bit concerned functionality wise that I do not
have a clean way to force the `new generator()` piece of code to be inside
of the generator.

I cannot easily convert it akin to how new can be caught:

function* generatorFn() {
  if (this instanceof generatorFn) {
    return new generatorFn // does not work

Since it will be wrapped.

So I guess a throw trap is the only way:

function* generatorFn() {
  if (this instanceof generatorFn) {
    throw new Error("This must be called with new");

But even then we are not able to tell if the generator is in
"standbyStartup" or the currently active `generatorFn`. Does the lack of
being able to test that make sense?

On Fri, Jan 24, 2014 at 8:40 AM, Domenic Denicola <
domenic at domenicdenicola.com> wrote:

>  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> 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> wrote:
>>  On Jan 23, 2014, at 4:49 PM, Brendan Eich <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
>> https://mail.mozilla.org/listinfo/es-discuss
>   _______________________________________________
> es-discuss mailing list
> 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/122ab5e3/attachment.html>

More information about the es-discuss mailing list