Let's kill terms "native" and "host"
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"?
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
> 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
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.
More information about the es-discuss