Let's kill terms "native" and "host"

Allen Wirfs-Brock allen at wirfs-brock.com
Sun Jan 29 11:25:35 PST 2012


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 <erights at google.com> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120129/2f65ac8e/attachment.html>


More information about the es-discuss mailing list