I think lthat in my next round of edits I want to update the terminology used in the ES spec. Below is my current thinking after factoring in the previous discussion on this thread:
object: An runtime entity that has identity and exposes properties (via implementations of the required "internal methods" specified in chapter 8) mundane object: An object that that uses only default behaviors for the required internal methods as specified in chapter 8. [and currently elsewhere until I do some reorganizing] exotic object: An object that provides non-default behavior for at least one of the required internal methods. Exotic objects encompasses Proxies and most of what are currently called "host objects". It also includes some chapter 15 objects such as array instances that have non-default internal method behaviors. Provider-based categorizations: standard object - An object whose application level semantics are defined by the ECMAScript specification. built-in object - an object that is provided by the ECMAScript implementation. platform object - An object that is provided by the environment that hosts the ECMAScript implementation. Each of the above three categorizations can include both mundane and exotic objects. The distinction between built-in object and platform object is probably of minor importance. Function terminology: function - An object that exposes the [[Call]] internal method. ECMAScript function - A function whose invocation result and side-effects is proved by evaluating ECMAScript code. alien function - A function whose invocation result and side-effects is provided in some manner other than by evaluating ECMAScript code. standard function - a function whose invocation result and side-effects defined by the ECMAScript specification (mostly chapter 15) An ECMAScript function might be either a mundane or an exotic object. An alien function is always an exotic object because the default [[Call]] internal method produces the invocation result and side-effects by evaluating ECMAScript code. A standard function can potentially be implemented either as an ECMAScript function or an alien function. I think all of the above terms have places where they are useful in the specification. If some aren't needed they can be dropped. Allen On Jan 29, 2012, at 11:25 AM, Allen Wirfs-Brock wrote: > Here is a first cut at some improved terminology: > > ECMAScript Object - an object whose primitive semantics are specified by the > ECMAScript specification > Foreign Object - an object whose primitive semantics differ from those > specified by the ECMAScript specification > > By "primitive semantics" I mean language level semantics defined by the > ECMAScript specification include the existence and specified behavor of > "internal properties". It does not mean "application level" semantics such > as the values of object properties or the actions performed by function > objects when called. > > Other terms that may be useful: > > Standard Object - An ECMAScript object whose application level semantics are > defined by the ECMAScript specification > Built-in Object - an object that is provided by the ECMAScript > implementation. A built-in object could be either an ECMAScript Object or a > Foreign Object > ECMAScript Function - an ECMAScript Object that has a [[Call]] internal > property. > Foreign Function - a Foreign Object that has a [[Call]] internal property > ECMAScript Code Function - an ECMAScript Function whose application level > semantics are defined using ECMAScript code > ECMAScript Foreign Code Function - an ECMAScript Function whose application > level semantics are defined in some manner other than with ECMAScript code > > Platform Object - An object that is provided by the environment that hosts > the ECMAScript implementation. A Platform Object could be either an > ECMAScript Object or a Foreign Object. (However, from a specification > perspective I don't see why this is really any different from a Built-in > Object as the ES implementation would have to provide the mechanism that > enabled a hosting platform to expose such objects and hence they would appear > to be "built-in") > > Note that objects that are implemented using Proxies are still ECMAScript > Objects because the primitive semantics of proxies are defined by the > ECMAScript specification. It may be useful to use > > > On Jan 29, 2012, at 10:19 AM, Wes Garland wrote: > >> On 28 January 2012 22:51, Mark S. Miller <[email protected]> wrote: >> Just because an object is provided as part of the host environment does >> *not* make it a host object. Given your statements above, I suspect that the >> Node objects you have in mind are all simply native objects provided by the >> Node hosting environment. If so, these are *not* host objects. >> >> I'm another person confused by the difference between host objects, native >> objects, and objects like "Math". Given that I haved worked trying to >> define the CommonJS host environment and that I write a lot of JS objects in >> C with SpiderMonkey, you'd think I would know the difference, but I don't. >> At least now I know I don't. I used to think I did, and that made reading >> the spec less useful. >> >> I think the least confusing way forward may be to drop the terms "host >> object" and "native object" completely from ES6. This isn't the first time >> that this list has spent many email thread time confusing "host objects" >> with "native objects provided by the host". By itself, this would suggest >> that the right terminology is "native" and "non-native". >> >> In my opinion, we need terminology describing objects which are provided by >> the host environment, and those which aren't. The language of >> implementation is completely irrelevant here. > > Platform Object > >> >> In GPSEE, we have CommonJS modules where exports can be functions >> implemented in JS or C -- in fact, we purposefully prototype in JS and then >> write C versions of "hot" library functions once code is in production. > > Assuming that standard [[Call]] semantics are use: Platform ECMAScript > Function which if implemented in ECMAScript is also a Platform ECMAScript > Code Function > >> >> Rhino embeddings can do similar things, implementing some methods in JS and >> others in Java. In this case, is a Java function native? > > Such Java implemented functions are ECMAScript Functions that are also > ECMAScript Foreign Code Functions >> >> Here's something even funnier -- if you use Object.prototype.bind in >> SpiderMonkey (Firefox 9) on a function written in JS userland and then call >> .toSource() on the result, it reports that the function is native! >> >> *head exploding* >> >> Wes >> >> -- >> Wesley W. Garland >> Director, Product Development >> PageMail, Inc. >> +1 613 542 2787 x 102 >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
