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
objects"?



>
> 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
>
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120130/36004809/attachment.html>


More information about the es-discuss mailing list