Editorial: don't overload [[Get]] / [[Set]] as an internal method name and internal slot name
[[Get]] is used as a internal method name and also an internal slot name in property descriptors.
This type of "overloading" is unfortunate: When searching for the [[Get]] method of something specific, it's unnecessary churn to go through the occurrences of [[Get]] as an internal slot name.
Suggestion 1: Rename [[Get]] and [[Set]] in property descriptors to [[Getter]] and [[Setter]].
Suggestion 2: Add a disambiguation table of things which have a [[Get]] internal method (+ links to them) and make [[Get]] everywhere link to it. (Currently [[Get]] doesn't link to anything.)
Yeah, we should definitely at least disambiguate. I like [[Getter]] and [[Setter]].
I'd like to make them link, too (see https://github.com/tc39/ecma262/issues/2047 / https://github.com/tc39/ecmarkup/issues/116), just haven't gotten to it. I like the idea of having a table listing all of the overloads as the place to link to, though of course it would have to call out that host exotic objects can have their own definitions which would not be listed.
This is a great suggestion. I'm especially excited about generalizing suggestion 2 to explicitly list out all the vtables of the objects that override internal method. Will take a stab at that after the plenary.
Renaming the slots is a nice small win for greppability, super on board.
Making internal operations navigable in any nonzero way? Priceless.
Renaming the slot might have consequences for integrating specs. We'd have to remember to search for any usages outside of 262 and send PRs updating them.
Technically, [[Get]] and [[Set]] are not internal slot names. A Property Descriptor is a Record, so they are field names there. Within an object, they are the names of two attributes of an accessor property.
Record field and slots name overlap occurs for these as well:
- [[Capability]]
- [[ECMAScriptCode]]
- [[Environment]]
- [[Module]]
- [[Promise]]
- [[Realm]]
- [[Strict]]
To me it seems especially confusing when they refer to the same concept but don’t have the same semantic significance, e.g. the function slot [[Strict]] vs the [[Strict]] field of Reference Records.
I think there’s a case to be made for not solving this by changing the names but by changing the syntax used to refer to record fields. Otherwise it’s likely to recur and in some cases, the duplicate names are reasonable, it’s just that it’s hard to tell what you’re “looking at”.