Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editorial convention for referring to intrinsics #2023

Closed
bakkot opened this issue May 31, 2020 · 10 comments · Fixed by #2056 or #2065
Closed

Editorial convention for referring to intrinsics #2023

bakkot opened this issue May 31, 2020 · 10 comments · Fixed by #2056 or #2065
Assignees

Comments

@bakkot
Copy link
Contributor

bakkot commented May 31, 2020

Some intrinsics have multiple names: for example, %AsyncGenerator% and %AsyncGeneratorFunction.prototype% name the same object. We should decide which we prefer, document that, and be consistent about which we use.

(This came up in #1781, e.g. 51072eb.)

@ljharb
Copy link
Member

ljharb commented May 31, 2020

The decision has already been that the dotted form should always be used, except in the Well-Known Intrinsics table, and also in the places where the non-dotted intrinsics are defined.

If there are any cases that deviate from this, let's please fix them.

Additionally, as soon as we can verify that HTML is no longer using an undotted form, it can and should be removed entirely from 262.

@bakkot
Copy link
Contributor Author

bakkot commented May 31, 2020

If there are any cases that deviate from this, let's please fix them.

There's a number of uses of %Generator% and %AsyncGenerator%, at least.

it can and should be removed entirely from 262.

I think it would be worth preserving these at least in a NOTE, for documentation purposes.

@ljharb
Copy link
Member

ljharb commented May 31, 2020

Generator and AsyncGenerator are top-level types, so I'd expect those to be the ones referenced.

I think it would be worth preserving these at least in a NOTE, for documentation purposes.

Totally fair; I'd expect that to be an entry in Annex E.

@bakkot
Copy link
Contributor Author

bakkot commented May 31, 2020

Generator and AsyncGenerator are top-level types

Not sure what you mean by top-level types. Neither is directly referenceable from the global object.

The way you get at %Generator% in userland is by doing (function*(){}).prototype, and the way you get at %GeneratorFunction% is by doing (function*(){}).prototype.constructor. So %Generator% can be written %GeneratorFunction.prototype%.

@ljharb
Copy link
Member

ljharb commented May 31, 2020

Sure - but if they were exposed, that's what would be.

Happy to chat on the call tho about preferring one over the other. Is there any contention about any of the globally-exposed intrinsics, and the intrinsics that are otherwise reachable dotting off of them?

@bakkot
Copy link
Contributor Author

bakkot commented May 31, 2020

Sure - but if they were exposed, that's what would be.

Well, no, it would be the object currently called %GeneratorFunction% which would be exposed. %Generator% is more like Function.prototype.

Happy to chat on the call tho about preferring one over the other. Is there any contention about any of the globally-exposed intrinsics, and the intrinsics that are otherwise reachable dotting off of them?

I don't really have strong opinions, I just want it to be settled and written down somewhere.

@devsnek
Copy link
Member

devsnek commented May 31, 2020

can we rename them to %(Async)GeneratorFunction.prototype% please, it is very confusing to differentiate "Generator" and "GeneratorFunction"

@ljharb
Copy link
Member

ljharb commented May 31, 2020

@devsnek i'm down with that if you do the prior research and ensure HTML and 402 (and other layered specs, if any) aren't using any "old" names.

@devsnek
Copy link
Member

devsnek commented May 31, 2020

@ljharb we would still leave the original names in the table

@ljharb
Copy link
Member

ljharb commented May 31, 2020

The ultimate goal is to delete the old names entirely imo.

@ljharb ljharb self-assigned this Jun 24, 2020
ljharb added a commit to ljharb/ecma262 that referenced this issue Jun 24, 2020
@bakkot bakkot removed the editor call to be discussed in the next editor call label Jul 1, 2020
ljharb added a commit to ljharb/ecma262 that referenced this issue Jul 5, 2020
ljharb added a commit to ljharb/ecma262 that referenced this issue Jul 16, 2020
ljharb added a commit to ljharb/ecma262 that referenced this issue Jul 18, 2020
ljharb added a commit to ljharb/ecma262 that referenced this issue Jul 26, 2020
ljharb added a commit to ljharb/ecma262 that referenced this issue Aug 5, 2020
ljharb added a commit to ljharb/ecma262 that referenced this issue Aug 5, 2020
ljharb added a commit to ljharb/ecma262 that referenced this issue Aug 10, 2020
ljharb added a commit to ljharb/ecma262 that referenced this issue Aug 10, 2020
ljharb added a commit to ljharb/ecma262 that referenced this issue Aug 11, 2020
ljharb added a commit to ljharb/ecma262 that referenced this issue Aug 25, 2020
@ljharb ljharb closed this as completed in 8f67a13 Aug 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants