More or less, but just language-exposed. And apart from those two, I don't think there's a major reason to expose most of the rest. About the only reason I've encountered to want to make that distinction for anything else with internal prototypes is object inspection.
Alternatively, we could expose `Iterator`/`AsyncIterator` constructors that happen to have their prototype properties set to the relevant iterator prototypes. That would arguably be more useful and flexible, since iterator classes could just `extends Iterator`, and if you want the object literal/`Object.create` route, you could just use `Iterator.prototype` or `AsyncIterator.prototype`. ----- Isiah Meadows [email protected] www.isiahmeadows.com On Tue, Aug 14, 2018 at 2:19 PM Jordan Harband <[email protected]> wrote: > > Something like this: > https://github.com/ljharb/es-abstract/blob/master/GetIntrinsic.js#L40-L46 or > https://github.com/tc39/test262/blob/c55d2ab7c344e35a3ceb93cf1d4d30019584db82/harness/wellKnownIntrinsicObjects.js > > On Tue, Aug 14, 2018 at 11:12 AM, Isiah Meadows <[email protected]> > wrote: >> >> When creating iterators and async iterators outside generators, it'd >> be *extremely* useful to have these exposed more easily accessible... >> >> Generators are *super* useful about 99% of the time in my experience, >> but there is that 1% where generators don't really work - this is not >> uncommon when you're adapting something to one of those two >> interfaces, like adapting an event emitter, and a few of the more >> complex operators, like "zip" (which is just easier to write using a >> raw iterator). >> >> ----- >> >> Isiah Meadows >> [email protected] >> www.isiahmeadows.com >> ----- >> >> Isiah Meadows >> [email protected] >> www.isiahmeadows.com >> >> >> On Tue, Aug 14, 2018 at 10:58 AM T.J. Crowder >> <[email protected]> wrote: >> > >> > This is the way I've found so far, allocating as few temporary objects as >> > possible (one, can't get rid of that temp function): >> > >> > ```js >> > const AsyncIteratorPrototype = >> > Object.getPrototypeOf( >> > Object.getPrototypeOf( >> > async function*(){} >> > ).prototype >> > ); >> > ``` >> > >> > or, showing the steps more clearly: >> > >> > ```js >> > const asyncGeneratorFunctionInstance = async function*(){}; >> > const AsyncGeneratorFunction = >> > Object.getPrototypeOf(asyncGeneratorFunctionInstance); >> > const AsyncGeneratorPrototype = AsyncGeneratorFunction.prototype; >> > const AsyncIteratorPrototype = >> > Object.getPrototypeOf(AsyncGeneratorPrototype); >> > ``` >> > >> > (I could create an async generator by calling that temporary async >> > generator function, but then I just have to do another >> > `Object.getPrototypeOf`, so it doesn't really buy me anything.) >> > >> > Is there something more direct? (Remember that `AsyncGeneratorFunction` >> > isn't globally exposed like `Function` is. None of the new subclasses of >> > Function constructors are exposed; according to [this thread][1], there >> > weren't enough strong use cases [that thread is for `GeneratorFunction`, >> > but we can extrapolate].) >> > >> > -- T.J. Crowder >> > >> > [1]: >> > https://esdiscuss.org/topic/why-generatorfunction-constructor-isn-t-directly-exposed-to-end-users >> > _______________________________________________ >> > es-discuss mailing list >> > [email protected] >> > https://mail.mozilla.org/listinfo/es-discuss >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
