Is this really the most direct way to get %AsyncIteratorPrototype%?

[Isiah Meadows]

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
contact at isiahmeadows.com
www.isiahmeadows.com
On Tue, Aug 14, 2018 at 2:19 PM Jordan Harband <ljharb at gmail.com> 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 <isiahmeadows at gmail.com> 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
>> contact at isiahmeadows.com
>> www.isiahmeadows.com
>> -----
>>
>> Isiah Meadows
>> contact at isiahmeadows.com
>> www.isiahmeadows.com
>>
>>
>> On Tue, Aug 14, 2018 at 10:58 AM T.J. Crowder
>> <tj.crowder at farsightsoftware.com> 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
>> > 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
>
>