-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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: Stop saying that a built-in function can be implemented as an ECMAScript function #3145
Conversation
<p>Built-in function objects that are not identified as constructors do not implement the [[Construct]] internal method unless otherwise specified in the description of a particular function. When a built-in constructor is called as part of a `new` expression the _argumentsList_ parameter of the invoked [[Construct]] internal method provides the values for the built-in constructor's named parameters.</p> | ||
<p>Built-in functions that are not constructors do not have a *"prototype"* property unless otherwise specified in the description of a particular function.</p> | ||
<p>If a built-in function object is not implemented as an ECMAScript function it must provide [[Call]] and [[Construct]] internal methods that conform to the following definitions:</p> | ||
<p>A built-in function object is an ordinary object; it must satisfy the requirements for ordinary objects set out in <emu-xref href="#sec-ordinary-object-internal-methods-and-internal-slots"></emu-xref>.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we <dfn>
"built-in function" here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, if we were going to <dfn>
"built-in function", this would be the section to do it. (Not with that sentence though, as it isn't a definition.) Is there an editorial policy on <dfn>
ing terms that already have a definition in Terms & Definitions?
(If there are editorial thoughts on disbanding "Terms & Definitions", please see Issue #1278.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
aa41b77
to
c7ab7ca
Compare
<p>Built-in functions that are not constructors do not have a *"prototype"* property unless otherwise specified in the description of a particular function.</p> | ||
<p>If a built-in function object is not implemented as an ECMAScript function it must provide [[Call]] and [[Construct]] internal methods that conform to the following definitions:</p> | ||
<p>A built-in function object is an ordinary object; it must satisfy the requirements for ordinary objects set out in <emu-xref href="#sec-ordinary-object-internal-methods-and-internal-slots"></emu-xref>.</p> | ||
<p>In addition to the internal slots required of every ordinary object, a built-in function object must also have the following internal slots:</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<p>In addition to the internal slots required of every ordinary object, a built-in function object must also have the following internal slots:</p> | |
<p>In addition to <a href="#sec-ordinary-object-internal-methods-and-internal-slots">the internal slots required of every ordinary object</a>, a built-in function object must also have the following internal slots:</p> |
<p>In addition to the internal slots required of every ordinary object, a built-in function object must also have the following internal slots:</p> | |
<p>In addition to the internal slots required of every ordinary object (see <emu-xref href="#sec-ordinary-object-internal-methods-and-internal-slots"></emu-xref>), a built-in function object must also have the following internal slots:</p> |
Maybe something like this to allow the reader to easily navigate there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems a bit overkill, given that the preceding sentence ended with a link to the same section. But done.
<p>The initial value of a built-in function object's [[Prototype]] internal slot is %Function.prototype%, unless otherwise specified.</p> | ||
<p>A built-in function object must have a [[Call]] internal method that conforms to the definition in <emu-xref href="#sec-built-in-function-objects-call-thisargument-argumentslist"></emu-xref>.</p> | ||
<p>A built-in function object has a [[Construct]] internal method if and only if it is described as a “constructor”, or some algorithm in this specification explicitly sets its [[Construct]] internal method. Such a [[Construct]] internal method must conform to the definition in <emu-xref href="#sec-built-in-function-objects-construct-argumentslist-newtarget"></emu-xref>.</p> | ||
<p>For a built-in function object defined in this specification, the behaviour specified for it via algorithm steps or other means is “the specification of _F_” for the purposes of step <emu-xref href="#step-call-builtin-function-result"></emu-xref> of <emu-xref href="#sec-builtincallorconstruct" title></emu-xref>.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like this paragraph could maybe be better accomplished via a note or clarification near that step of BuiltinCallOrConstruct
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've recast it as a NOTE-step in BuiltinCallOrConstruct
. It's almost a tautology, but I think it might be helpful.
Looking it over, I think I lost something from the status quo's "behaviour for both [[Call]] and [[Construct]] invocations", so I've added another sentence to 18 "ECMAScript Standard Built-in Objects".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM otherwise.
c7ab7ca
to
cf9a79e
Compare
cf9a79e
to
ce52d69
Compare
- Delete prose that repeats step 10 of BuiltinCallOrConstruct. - Move one sentence to a NOTE-step in BuiltinCallOrConstruct. - Move two sentences to 18 "ECMAScript Standard Built-in Objects". - Reword the remains of "Built-in Function Objects".
ce52d69
to
a651255
Compare
- Delete prose that repeats step 10 of BuiltinCallOrConstruct. - Move one sentence to a NOTE-step in BuiltinCallOrConstruct. - Move two sentences to 18 "ECMAScript Standard Built-in Objects". - Reword the remains of "Built-in Function Objects".
(... and other tweaks to 10.3 "Built-in Function Objects")
This covers much the same ground as #3007, but takes a different enough approach that I figured it should be a separate PR.
Commit 1 eliminates anything that says a built-in function can be implemented as an ECMAScript function. (This doesn't eliminate the possibility that it can be implemented that way, just leaves it unsaid.)
Commit 2 deletes prose that just repeats step 10 of built-in [[Call]] and [[Construct]]. (As suggested by Editorial: Re-word re built-in function implemented as ECMAScript function #3007 (comment))
Commit 3 moves a single-sentence paragraph about the
"prototype"
property of built-in functions from 10.3 "Built-in Function Objects" to 18 "ECMAScript Standard Built-in Objects". (Other than that sentence, 10.3 doesn't say anything about properties, whereas 18 says lots about properties, so 18 seems like a more appropriate location.) This starts to get into some of the territory covered by PR Editorial: Remove function-specific text from object-specific section #539. (In particular, I made the same suggestion at the bottom of Editorial: Remove function-specific text from object-specific section #539 (comment).)Commit 4 then re-works everything left in 10.3 "Built-in Function Objects". The organization is roughly the same (talk about internal slots, then talk about internal methods), but I think the flow is better. Also: