Make the Iterator prototype have its own constructor #730
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change makes the generator prototype chain fully conformant with
the specthe Iterator Helpers stage 3 proposal, and enables the following code to work when transpiled to older runtimes:Of course, the above already works, but since
Iterator.prototype
currently returns the globalObject
prototype, installingforEach
installs on all objects, which is not the intent, andRepeatIterator
is not able to function as anIterable
, because it does not have the[Symbol.iterator]
method. So, notably, with this PR, this will work as well:Also, note the above already works if regenerator is used in a standard configuration with preset-env in babel and core-js 3 is
require
d (which polyfills the Iterator constructor, and regenerator picks that up as the "native" Iterator prototype), however, regenerator is already almost fully compliant with the prototype chain spec for generators, and I figured it is good for completeness to add this here, as maybe there are cases where regenerator is not used in that combination with the latest core-js that supplies a proper Iterator constructor implementation.Unit tests have been added.
Addendum
I also went ahead and merged
GeneratorFunctionPrototype
intoGenerator
, because the two were duplicates --Generator
is the prototype ofGeneratorFunction
!GeneratorFunctionPrototype
was actually the one that was fully setup andGenerator
was not referenced anywhere in the prototype+constructor chain, except it had its ownprototype
property set , which allowed it to be used in aninstanceof
test. That test looks atGenerator.prototype
only, and because bothGenerator.prototype
andGeneratorFunctionPrototype.prototype
were set to the sameGeneratorPrototype
object, bothGenerator
andGeneratorFunctionPrototype
are interchangeable in this position!In the graphic you can see GFP (
GeneratorFunctionPrototype
in the code) as the object properly setup in the prototype chain andGenerator
is crossed out. You can think of the change as a two-step - 1) removeGenerator
, 2) renameGeneratorFunctionPrototype
toGenerator
.