Let's kill terms "native" and "host"
Mark S. Miller
erights at google.com
Mon Jan 30 10:19:56 PST 2012
On Sun, Jan 29, 2012 at 1:25 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>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
Can we get rid of the concept of "Foreign Object" entirely, and just treat
all the objects we have in mind (e.g. DOM nodes) as "Built in proxy
> 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
> 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*
> Wesley W. Garland
> Director, Product Development
> PageMail, Inc.
> +1 613 542 2787 x 102
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss