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

Brendan Eich brendan at mozilla.org
Mon Jan 30 10:56:26 PST 2012


> Mark S. Miller <mailto:erights at google.com>
> January 30, 2012 10:19 AM
> On Sun, Jan 29, 2012 at 1:25 PM, Allen Wirfs-Brock 
> <allen at wirfs-brock.com <mailto: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"?

+lots, again.

We need to shaver closer with Occam's razor. I do not think "Built-in" 
is a useful distinction below:
>
>     [Allen wrote] 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
>

Nit: please avoid "ECMAScript" all over. It's ugly and overlong. We 
should use the shortest unambiguous phrase we can, clearly defined in 
the spec as a term of art.

Obvious antonyms: (native, foreign), (native, alien). But "native" is 
confusing due to other meanings in common use nearby and even in common 
JS parlance (and in ECMA-262, till we fix it).

Proposal: use "naive" not "native". The antonym is "proxy" (not 
"sophisticated" :-P). Five letters each, short and sweet. We can make 
the definition clear in the spec.

Then the only distinction ignoring built-in vs. self-hosted is whether 
an object can be implemented in JS using non-proxy intercession 
(accessors, certain methods called implicitly), vs. whether it requires 
computation (traps) behind operations not interceded-for by accessors 
and methods.

Notice that proxies may have C++ (if that's the host language) traps as 
well as JS. That's not an issue (we do it in Firefox) in terms of power. 
Again, I agree with Mark (and Tom): we should tame all objects to be 
naive or proxy.

/be


More information about the es-discuss mailing list