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
