On Sun, Jan 29, 2012 at 1:25 PM, Allen Wirfs-Brock <[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"? > > 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 <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
