Editorial: consider built-in functions to be ordinary objects #2969
Conversation
There was a problem hiding this comment.
Given this change, 10.3 "Built-in Function Objects" is now incorrect. It says that a built-in function may be implemented as either:
- an ECMAScript function object (using 10.2.1 [[Call]]), or
- a function exotic object, using 10.3.1 [[Call]].
But in this PR, an object using 10.3.1 [[Call]] is no longer exotic.
10.3 has 3 occurrences of "exotic". I suggest the following fixes:
- Delete the first.
- Change "is implemented as an exotic object" to "is not implemented as an ECMAScript function object".
- Delete the third.
(Interestingly, the resulting wording is also compatible with the status quo's definition of ordinary function.)
In the status quo, "ordinary function" means the same as "ECMAScript function",
so "Ordinary" is used in the names of various operations that are specific to ECMAScript functions:
- PrepareForOrdinaryCall
- OrdinaryCallBindThis
- OrdinaryCallEvaluateBody
- OrdinaryFunctionCreate
But in this PR, ECMAScript functions become a subset of ordinary functions, so using "Ordinary" in these contexts is misleading, so the operations should maybe be renamed. Possibly:
- "OrdinaryCall" -> "ECMAScriptFunctionCall"
- OrdinaryFunction" -> "ECMAScriptFunction"
bakkot
added
the
ready to merge
As I point out there, I don't think it resolves my concern. (Which might affect whether you want to merge it, but might not.) |
ljharb
force-pushed
the
builtin-functions-are-ordinary-too
branch
from
b88b73f to
907276f
Compare
PR tc39#2969 changed the definition of "ordinary function" to include all built-in functions (however implemented). So change "an exotic built-in function object" to "a built-in function object that is not an ECMAScript function object". Yes, this is somewhat ugly. I'm hoping it's temporary until the spec stops caring about how a built-in is implemented.
This should implement the resolution to @jmdyck's concern in #2942 (comment).