Editorial: Drop [[ScriptOrModule]] slot for exotic built-ins #2190
Conversation
spec.html
Outdated
| @@ -8553,7 +8553,7 @@ <h1>FunctionDeclarationInstantiation ( _func_, _argumentsList_ )</h1> | |||
| <emu-clause id="sec-built-in-function-objects"> | |||
| <h1>Built-in Function Objects</h1> | |||
| <p>The built-in function objects defined in this specification may be implemented as either ECMAScript function objects (<emu-xref href="#sec-ecmascript-function-objects"></emu-xref>) whose behaviour is provided using ECMAScript code or as implementation provided function exotic objects whose behaviour is provided in some other manner. In either case, the effect of calling such functions must conform to their specifications. An implementation may also provide additional built-in function objects that are not defined in this specification.</p> | |||
| <p>If a built-in function object is implemented as an exotic object it must have the ordinary object behaviour specified in <emu-xref href="#sec-ordinary-object-internal-methods-and-internal-slots"></emu-xref>. All such function exotic objects also have [[Prototype]], [[Extensible]], [[Realm]], and [[ScriptOrModule]] internal slots.</p> | |||
There was a problem hiding this comment.
it seems very strange to me that all functions wouldn't all have the same slots, even if it's null for this subset. What's the benefit of dropping it?
There was a problem hiding this comment.
exotic objects don't all have the same slots
There was a problem hiding this comment.
Surely not, but generally each category of thing shares the same slots, even if the values are different.
There was a problem hiding this comment.
You might say all functions have [[Prototype]], [[Extensible]], and [[Realm]], to satisfy the invariants of the language, and [[ScriptOrModule]] is an additional slot on ECMAScript Source Text functions (and not the only one) as they come from a script or module.
There was a problem hiding this comment.
it seems very strange to me that all functions wouldn't all have the same slots, even if it's null for this subset.
Table 28 lists 11 internal slots (in addition to [[Prototype]] and [[Extensible]]) that every ordinary function must have. An exotic function isn't required to have any of those, except (e.g.) where it's implementing a built-in, in which case it's currently required to have 4 of those 13 slots. This PR just reduces that 4 to 3. Are you saying that every function object should be required to have all 13?
There was a problem hiding this comment.
You might say all functions have
[[Prototype]], [[Extensible]], and [[Realm]], to satisfy the invariants of the language,
That would be incorrect.
- Bound function exotic objects don't have
[[Realm]]. - Proxy function objects don't have any of those (just
[[ProxyHandler]]and[[ProxyTarget]]). - Non-standard exotic functions aren't required to have any internal slots.
There was a problem hiding this comment.
Right sorry I was more trying to say, whatever all objects happen to have is what they share, it's a cyclical definition.
|
Does it related to https://github.com/Jack-Works/proposal-strict-built-in-functions? |
I don't think so. That proposal appears to be normative, whereas this PR is editorial. |
A built-in function that is implemented as an exotic object has no need for a [[ScriptOrModule]] internal slot. It always has the value `*null*`, and the only place it's used is in [the [[Call]] and [[Construct]] methods for exotic built-ins](sec-built-in-function-objects-call-thisargument-argumentslist), so we can just inline `*null*` there. The remaining 3 appearances of [[ScriptOrModule]] pertain only to ordinary functions. (Setting [[ScriptOrModule]] for exotic built-ins made more sense when the slot was introduced, because of the way GetActiveScriptOrModule() was written, but PR tc39#556 changed it to basically the current situation.)
ljharb
force-pushed
the
ScriptOrModule
branch
from
51c12c7 to
0b3a808
Compare
A built-in function that is implemented as an exotic object has no need for a
[[ScriptOrModule]]internal slot. It always has the value*null*, and the only place it's used is in the [[Call]] and [[Construct]] methods for exotic built-ins, so we can just inline*null*there.The remaining 3 appearances of
[[ScriptOrModule]]pertain only to ordinary functions.(Setting
[[ScriptOrModule]]for exotic built-ins made more sense when the slot was introduced, because of the wayGetActiveScriptOrModule()was written, but PR #556 changed it to basically the current situation.)