Mark S. Miller <mailto:[email protected]>
January 30, 2012 10:19 AM
On Sun, Jan 29, 2012 at 1:25 PM, Allen Wirfs-Brock
<[email protected] <mailto:[email protected]>> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
