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: Normalize casing of "built-in function" #530

Merged
merged 1 commit into from
Apr 8, 2016

Conversation

gibson042
Copy link
Contributor

No description provided.

@bterlson
Copy link
Member

bterlson commented Apr 8, 2016

Nice, thanks!

@bterlson bterlson merged commit 6a13789 into tc39:master Apr 8, 2016
@michaelficarra
Copy link
Member

@bterlson You sure you want to do this? I believe @allenwb intentionally used this capitalisation. Search the spec for [A-Z]\w+ object.

@rwaldron
Copy link
Contributor

@bterlson I think @michaelficarra may be right, there is evidence in some of these same sentences where "String" is used, not "string". I'm going to dig around a bit further for more compelling evidence

@bterlson
Copy link
Member

@michaelficarra I thought about renaming to Function object instead but the lower case form is used predominantly across the spec (and used in the dfn). Unless I'm missing something, there is no semantic distinction between the casings?

@michaelficarra
Copy link
Member

@bterlson It's not just "Function object". Throughout the spec, I see "Date object", "Boolean object", "String object", "Number object", "Symbol object", "Proxy object", "Array object", "IteratorResult object", "RegExp object", "Iterator object", "Error object", "TypedArray object", "Map object", "Set object", "WeakMap object", "WeakSet object", "ArrayBuffer object", "DataView object", "GeneratorFunction object", "Generator object", and "Promise object". While it might not be semantic, the pattern I see is that any reference to "a/an X object" is an instance of the standard built-in constructor with the name "X". Additionally, "Boolean / String / Number / Symbol object" are defined as

member of the Object type that is an instance of the standard built-in Boolean / String / Number / Symbol constructor

@allenwb
Copy link
Member

allenwb commented Apr 11, 2016

Yes, the phrasing "a Foo object" meaning "an instance of the standard built-in constructor Foo" goes back to very early editions of EMA-262.

"function" and "Function object" historically have had different meanings. "Function object" means an instance of the built-in Function constructor". A "function" is a callable object (ie, an object with a [[Call]] internal method". A function is snot necessarily a Function object.

@bterlson
Copy link
Member

@allenwb Hmm ok, I was thinking that 9.2 function objects were instances but I see that is not the case. Thanks! Will revert.

@allenwb
Copy link
Member

allenwb commented Apr 11, 2016

You might consider replacing any occurrences of "function object" (note lowercase f) with "function" since all "functions" are objects.

For example, "ECMAScript function object" could just be "ECMAScript function"

@gibson042
Copy link
Contributor Author

Semantic meaning attached to word casing was precisely what motivated this pull request—"built-in Function" is potentially ambiguous (callable built-in object vs. singular %Function% intrinsic object/Function constructor), but "built-in function" is not. Further, as @bterlson notes, the lowercase form was already predominant, including in the description of the Function constructor and in the establishment of "built-in function" as a term. And finally, while I would advocate a similar cleanup of the other types, they don't suffer the same ambiguity because it is almost always clear from context whether text is referencing e.g. an array instance or the %Array% Array constructor—it is only functions and objects that self-describe in this way, and "built-in object" is consistently lowercase. "Built-in function" should be as well.

@bterlson
Copy link
Member

@gibson042 what you say is all true (and motivated me to accept this PR in the first place), but what @allenwb says is also true - that there is an important (to the spec) semantic distinction here. I think @allenwb's suggestion of renaming the lowercase "function object" to just "function" would go a long way to alleviating some of this confusion. What do you think?

bterlson added a commit that referenced this pull request Apr 12, 2016
This reverts commit 6a13789.
There is an important semantic distinction between built-in function
and built-in Function.
@gibson042
Copy link
Contributor Author

I think @allenwb's suggestion of renaming the lowercase "function object" to just "function" would go a long way to alleviating some of this confusion. What do you think?

I concur, especially since section 4.3 defines "function" and "built-in function", but not "function object" or "built-in function object". So are you proposing renaming all instances of "function object", or only those preceded by "built-in"?

EDIT: The "Function" versions are likewise undefined, as far as I can tell.

@gibson042
Copy link
Contributor Author

@bterlson @allenwb Seeing #697 reminded me about this being reverted. What would it take to revive it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants