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

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

# Mark S. Miller (13 years ago)

[new subject line]

On Sat, Jan 28, 2012 at 12:03 PM, Dmitry Soshnikov < dmitry.soshnikov at gmail.com> wrote: [...]

Moreover, many "host" objects are implemented in JS itself -- e.g. some standard libraries as in Node.js. I called them inefficiently as "native-host" objects.

I'm not as familiar with Node as I should be, but this surprises me. Can you give an example?

But from this viewpoint -- is this algorithm step is correct? I.e. window.opera being as a native-host can nevertheless have as its [[NativeBrand]] values of "Array", "Object", etc?

And a host object then becomes as "an object provided by a host environment and has semantic differentiations from this specification".

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

But our "native" term causes even worse confusion! Java taught everyone that "native" means "not implemented in Java". I have seen many discussions and IIRC even some documentation that used the term "native" analogously, to mean "not implemented in JavaScript". This is worse than useless, since all "non-native"(spec_language) objects are "native"(popular_language) objects, and all "non-native"(popular_language) objects are "native"(spec_language) objects. Whenever I am about to use the term "native" to someone not on the committee or on this list, I usually preface it with "It means the opposite of what you expect".

# Mark S. Miller (13 years ago)

On Sat, Jan 28, 2012 at 2:27 PM, John-David Dalton < john.david.dalton at gmail.com> wrote:

@MarkM

Is there something magical about the behavior of this object itself?

For kicks the "magical" bit would be its awesome pre ES6 internal [[Class]] value.

Sigh. I just tested an you are correct.

> ({}).toString.call(window.opera)
[object Opera]

It feels paradoxical but it isn't, quite. Even if there is nothing else magical about this object, that response is indeed magical enough to classify it as a host object, thereby requiring some such response. So it is self consistent. If there is indeed nothing else magical about it, I would encourage future versions of Opera to provide a native object here instead, which is identical but for the above response.

Can we leave "magical" out of a spec convo?

It was intended only for humorous emphasis. But even "magical" and "non magical" would be less confusing than the current terminology!

Note that just because the object itself is non-standard and provided by the host does not make it a host object.

es5.github.com/#x4.3.8 A host object is an "object supplied by the host environment to complete the execution environment of ECMAScript."

Sigh. This came up last time as well, and as participants in the spec writing process our only excuse was "That text isn't normative". That doesn't really excuse it from being so wrong that it leads people into endless confusion. If ES6 does keep the current terminology, we must at least fix or remove this confusing text.

# Brendan Eich (13 years ago)

Mark S. Miller wrote:

I think the least confusing way forward may be to drop the terms "host object" and "native object" completely from ES6.

+∞!

# David Herman (13 years ago)

On Jan 28, 2012, at 8:04 PM, Mark S. Miller wrote:

Can we leave "magical" out of a spec convo?

It was intended only for humorous emphasis. But even "magical" and "non magical" would be less confusing than the current terminology!

In some PL research circles, they use "exotic" as a somewhat less laden term for "outside the usual realm of expectations."

# Wes Garland (13 years ago)

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.

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.

Rhino embeddings can do similar things, implementing some methods in JS and others in Java. In this case, is a Java function native?

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

# Allen Wirfs-Brock (13 years ago)

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

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

# Andreas Rossberg (13 years ago)

On 29 January 2012 20:25, 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

+1. Instead of "EcmaScript object" you could also say "language object".

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

Hm, how would proxies tie in here? According to your definition, they'd count as standard objects, which I would find rather confusing. Or do you also want to distinguish "proper objects", maybe?

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

The last two seem a bit obscure, especially since the spec doesn't really talk about code. Also, for e.g. function proxies, it is not really clear what code this is referring to (the call trap? the construct trap? what if the call trap is itself a function proxy whose call trap is foreign?).

# Tom Van Cutsem (13 years ago)

On 29 January 2012 20:25, 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

Gilad Bracha has been using the term "aliens" for "Foreign Objects" in Newspeak. It's shorter, and to me sounds less awkward than having to refer to a Foreign object as a "foreigner" ;-)

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

The last two seem a bit obscure, especially since the spec doesn't really talk about code. Also, for e.g. function proxies, it is not really clear what code this is referring to (the call trap? the construct trap? what if the call trap is itself a function proxy whose call trap is foreign?).

I agree there's room for improvement, but proxies are weird beasts in this respect. For direct proxies though, I have a principled answer: I'd classify function proxies recursively as however their target would be classified. So if the target is an ECMAScript Code Function, so is the proxy. If the target is foreign, so is the proxy. This is consistent with the way typeof and [[Class]] are specified for direct proxies in general.

# Allen Wirfs-Brock (13 years ago)

On Jan 30, 2012, at 2:10 AM, Andreas Rossberg wrote:

On 29 January 2012 20:25, 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

+1. Instead of "EcmaScript object" you could also say "language object".

I avoided "language" in hope of not creating confusion with the concept I called "ECMAScript Code Function".

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

Hm, how would proxies tie in here? According to your definition, they'd count as standard objects, which I would find rather confusing. Or do you also want to distinguish "proper objects", maybe?

this was part of what I was trying to get at in using the phrase "application level semantics". The distinction really isn't very different from object created via object literals (or any other standard mechanism). They clearly are ECMAScript objects but because they have arbitrary properties defined by the application they are not "standard objects".

That said, "Standard Object" was the last definition I added and the concept and perhaps the terminology probably needs some more work.

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

The last two seem a bit obscure, especially since the spec doesn't really talk about code. Also, for e.g. function proxies, it is not really clear what code this is referring to (the call trap? the construct trap? what if the call trap is itself a function proxy whose call trap is foreign?).

Actually, the spec. does use this distinction.

For example, the "Creating Function Objects" algorithm in 13.2 is specifically for ECMAScript Code Functions as are the [[Call]] internal method in 13.2.2.

More generally, the ES5 spec. used the term "ECMAScript code function" with this meaning. See for example, 10.4

Regarding proxies, I believe it would be the call trap, but by design it is with proxies where these concepts get murky.

# Wes Garland (13 years ago)

On 30 January 2012 11:56, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

this was part of what I was trying to get at in using the phrase "application level semantics". The distinction really isn't very different from object created via object literals (or any other standard mechanism). They clearly are ECMAScript objects but because they have arbitrary properties defined by the application they are not "standard objects".

So, a good example here would be E4X objects? (Ignoring that E4X is a standard, let's pretend they are engine vendor bolt-ons). They have behaviours different from standard ES objects; the first one that pops to mind is that is possible for two E4X objects to be == but not ===.

# Allen Wirfs-Brock (13 years ago)

On Jan 30, 2012, at 9:05 AM, Wes Garland wrote:

On 30 January 2012 11:56, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote: this was part of what I was trying to get at in using the phrase "application level semantics". The distinction really isn't very different from object created via object literals (or any other standard mechanism). They clearly are ECMAScript objects but because they have arbitrary properties defined by the application they are not "standard objects".

So, a good example here would be E4X objects? (Ignoring that E4X is a standard, let's pretend they are engine vendor bolt-ons). They have behaviours different from standard ES objects; the first one that pops to mind is that is possible for two E4X objects to be == but not ===.

Ignoring the "standard issue" , I would classify E4X objects as foreign objects and probably as built-in foreign objects.

Strictly speaking, E4X isn't just introducing foreign objects. Some of the semantics such as ==/=== would seem to require language changes that can't be accounted for by the extension points of the object model. For example, one or more new ECMAScript language types needs to be defined and the == algorithm in 11.9.3 should have to be modified.

# Mark S. Miller (13 years ago)

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

# Allen Wirfs-Brock (13 years ago)

On Jan 30, 2012, at 10:19 AM, Mark S. Miller wrote:

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

Possibly, but my gut says that is a step too far for this iteration of the spec. If we could, then we could also get rid of all internal redefinition of the internal methods and replace all chapter 15 objects specifications with Proxy based definitions. It may be possible, but I'm worried that we don't yet understand reflection upon proxies well enough yet to expose the built-ins in that manner. It also it clear to me whether proxies are yet power enough to accomplish everything that is currently done with "host objects".

# Brendan Eich (13 years ago)

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.

# Brendan Eich (13 years ago)

Allen Wirfs-Brock wrote:

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

Possibly, but my gut says that is a step too far for this iteration of the spec. If we could, then we could also get rid of all internal redefinition of the internal methods and replace all chapter 15 objects specifications with Proxy based definitions.

Array is a hard case, but most of the clause 15 objects do not need to be proxies, IINM. Some need private-named (formerly "internal") properties, but that's a subclassing fix we want.

It may be possible, but I'm worried that we don't yet understand reflection upon proxies well enough yet to expose the built-ins in that manner. It also it clear to me whether proxies are yet power enough to accomplish everything that is currently done with "host objects".

We should do a stress-test on implementations and other specs that claim to need more than what proxies now provide. I think we can ignore the legacy stuff in WebIDL -- it can still be outlaw. What we want is a smaller ECMA-262 that biases for the future.

# Oliver Hunt (13 years ago)

On Jan 30, 2012, at 11:00 AM, Brendan Eich wrote:

Allen Wirfs-Brock wrote:

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

Possibly, but my gut says that is a step too far for this iteration of the spec. If we could, then we could also get rid of all internal redefinition of the internal methods and replace all chapter 15 objects specifications with Proxy based definitions.

Array is a hard case, but most of the clause 15 objects do not need to be proxies, IINM. Some need private-named (formerly "internal") properties, but that's a subclassing fix we want.

It may be possible, but I'm worried that we don't yet understand reflection upon proxies well enough yet to expose the built-ins in that manner. It also it clear to me whether proxies are yet power enough to accomplish everything that is currently done with "host objects". We should do a stress-test on implementations and other specs that claim to need more than what proxies now provide. I think we can ignore the legacy stuff in WebIDL -- it can still be outlaw. What we want is a smaller ECMA-262 that biases for the future.

I think there's been a general move to kill off the various magic properties in webidl defined objects and replace them with getters/setters on the prototype. I think that the bulk of the DOM ends up relatively trivially becoming "regular" objects at that point.

Remaining problems are the DynamicNodeLists and related types (where things like the number and value of properties changes externally from JS) which seems like something that could be hidden behind a wall of "this is just a proxy", similar for the compat. layers like window.someElementName.

# Allen Wirfs-Brock (13 years ago)

On Jan 30, 2012, at 11:17 AM, Oliver Hunt wrote:

On Jan 30, 2012, at 11:00 AM, Brendan Eich wrote:

Allen Wirfs-Brock wrote:

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

Possibly, but my gut says that is a step too far for this iteration of the spec. If we could, then we could also get rid of all internal redefinition of the internal methods and replace all chapter 15 objects specifications with Proxy based definitions.

Array is a hard case, but most of the clause 15 objects do not need to be proxies, IINM. Some need private-named (formerly "internal") properties, but that's a subclassing fix we want.

It may be possible, but I'm worried that we don't yet understand reflection upon proxies well enough yet to expose the built-ins in that manner. It also it clear to me whether proxies are yet power enough to accomplish everything that is currently done with "host objects". We should do a stress-test on implementations and other specs that claim to need more than what proxies now provide. I think we can ignore the legacy stuff in WebIDL -- it can still be outlaw. What we want is a smaller ECMA-262 that biases for the future.

I think there's been a general move to kill off the various magic properties in webidl defined objects and replace them with getters/setters on the prototype. I think that the bulk of the DOM ends up relatively trivially becoming "regular" objects at that point.

Remaining problems are the DynamicNodeLists and related types (where things like the number and value of properties changes externally from JS) which seems like something that could be hidden behind a wall of "this is just a proxy", similar for the compat. layers like window.someElementName.

The Object Model Reformation proposal strawman:object_model_reformation offers another approach for accommodating things like HTML node lists.

From the PoV of JSC I suspect our biggest problem will actually be our API, which essentially allows developers to override an arbitrary collection of [[SomeInternalMethod]] methods, potentially inconsistently (a sad fact of our api is that you can override [[HasProperty]] and [[GetProperty]] independently, and have them be inconsistent :(

Some of this factoring appears to have been done simply for economy of expression. I'm all for cleaning up the internal methods to eliminate such unneeded flexibility and to bring them inline with Proxy handlers.

# Andreas Rossberg (13 years ago)

On 30 January 2012 20:17, Oliver Hunt <oliver at apple.com> wrote:

From the PoV of JSC I suspect our biggest problem will actually be our API, which essentially allows developers to override an arbitrary collection of [[SomeInternalMethod]] methods, potentially inconsistently (a sad fact of our api is that you can override [[HasProperty]] and [[GetProperty]] independently, and have them be inconsistent :(

Well, it's not like the language's own object API (a.k.a. proxies) is any better in that respect... ;)

# Brendan Eich (13 years ago)

Andreas Rossberg wrote:

On 30 January 2012 20:17, Oliver Hunt<oliver at apple.com> wrote:

From the PoV of JSC I suspect our biggest problem will actually be our API, which essentially allows developers to override an arbitrary collection of [[SomeInternalMethod]] methods, potentially inconsistently (a sad fact of our api is that you can override [[HasProperty]] and [[GetProperty]] independently, and have them be inconsistent:(

Well, it's not like the language's own object API (a.k.a. proxies) is any better in that respect...;)

It's still a win to have fewer such mouths to feed, and in particular, only one such mouth in the spec. I hope you're just reminding that proxies can be abused to violate invariants that we cannot enforce (efficiently or at all), not putting proxies into the same low class as JSC's (or SpiderMonkey's, or any other engine's) old/over-broad embedding API.

# Oliver Hunt (13 years ago)

On Jan 30, 2012, at 11:41 AM, Allen Wirfs-Brock wrote:

From the PoV of JSC I suspect our biggest problem will actually be our API, which essentially allows developers to override an arbitrary collection of [[SomeInternalMethod]] methods, potentially inconsistently (a sad fact of our api is that you can override [[HasProperty]] and [[GetProperty]] independently, and have them be inconsistent :(

Some of this factoring appears to have been done simply for economy of expression. I'm all for cleaning up the internal methods to eliminate such unneeded flexibility and to bring them inline with Proxy handlers.

Oh, this is specifically a JSC issue, it's not a spec related problem -- we have API and ABI that guarantee these bits of weirdness are possible, so it's simply going to be a matter of trying to work around them, or otherwise mask the behaviour without impacting existing clients. No change in the spec can effect our existing API -> property attributes are still DontDelete, etc in C code, because anything would break source compat, what fun!

# Tom Van Cutsem (13 years ago)

2012/1/30 Brendan Eich <brendan at mozilla.org>

Andreas Rossberg wrote:

On 30 January 2012 20:17, Oliver Hunt<oliver at apple.com> wrote:

From the PoV of JSC I suspect our biggest problem will actually be our API, which essentially allows developers to override an arbitrary collection of [[SomeInternalMethod]] methods, potentially inconsistently (a sad fact of our api is that you can override [[HasProperty]] and [[GetProperty]] independently, and have them be inconsistent:(

Well, it's not like the language's own object API (a.k.a. proxies) is any better in that respect...;)

It's still a win to have fewer such mouths to feed, and in particular, only one such mouth in the spec. I hope you're just reminding that proxies can be abused to violate invariants that we cannot enforce (efficiently or at all), not putting proxies into the same low class as JSC's (or SpiderMonkey's, or any other engine's) old/over-broad embedding API.

Proxies (also direct proxies) can indeed expose inconsistencies between fundamental and derived traps, but throwing away the derived traps in favor of removing such inconsistencies seems like a bridge too far. Not only is there economy of expression to consider (it's logical that the expression |name in obj| triggers a "has" trap that directly corresponds to the intercepted operation), but derived traps in general need to perform less object allocations to produce a result.

For instance, if the expression |name in obj| would trigger the "getOwnPropertyDescriptor" trap instead of the "has" trap, a property descriptor could be allocated only to have the in-operator test whether the descriptor is undefined.

Also, we provide the VirtualHandler API < harmony:virtual_object_api> to make

it easier for developers to just implement fundamental traps and inherit derived trap fallback implementations. When used properly, proxies with such a handler will never be internally inconsistent.

So, I don't think "derived" internal methods such as [[HasProperty]] necessarily need to be refactored, other than to the extent described in the "proto climbing refactoring" proposal < harmony:proto_climbing_refactoring>.

# Andreas Rossberg (13 years ago)

On 31 January 2012 12:40, Tom Van Cutsem <tomvc.be at gmail.com> wrote:

2012/1/30 Brendan Eich <brendan at mozilla.org>

Andreas Rossberg wrote:

On 30 January 2012 20:17, Oliver Hunt<oliver at apple.com>  wrote:

From the PoV of JSC I suspect our biggest problem will actually be our API, which essentially allows developers to override an arbitrary collection of [[SomeInternalMethod]] methods, potentially inconsistently (a sad fact of our api is that you can override [[HasProperty]] and [[GetProperty]] independently, and have them be inconsistent:(

Well, it's not like the language's own object API (a.k.a. proxies) is any better in that respect...;)

It's still a win to have fewer such mouths to feed, and in particular, only one such mouth in the spec. I hope you're just reminding that proxies can be abused to violate invariants that we cannot enforce (efficiently or at all), not putting proxies into the same low class as JSC's (or SpiderMonkey's, or any other engine's) old/over-broad embedding API.

Proxies (also direct proxies) can indeed expose inconsistencies between fundamental and derived traps, but throwing away the derived traps in favor of removing such inconsistencies seems like a bridge too far.

Yeah, I didn't intend to imply that we should change proxies, but only that Oliver doesn't need to be overly sad about JSC's API.

# Allen Wirfs-Brock (13 years ago)

I think lthat in my next round of edits I want to update the terminology used in the ES spec.
Below is my current thinking after factoring in the previous discussion on this thread:

object: An runtime entity that has identity and exposes properties (via implementations of the required "internal methods" specified in chapter 8) mundane object: An object that that uses only default behaviors for the required internal methods as specified in chapter 8. [and currently elsewhere until I do some reorganizing] exotic object: An object that provides non-default behavior for at least one of the required internal methods.

Exotic objects encompasses Proxies and most of what are currently called "host objects". It also includes some chapter 15 objects such as array instances that have non-default internal method behaviors.

Provider-based categorizations:

standard object - An object whose application level semantics are defined by the ECMAScript specification. built-in object - an object that is provided by the ECMAScript implementation. platform object - An object that is provided by the environment that hosts the ECMAScript implementation.

Each of the above three categorizations can include both mundane and exotic objects. The distinction between built-in object and platform object is probably of minor importance.

Function terminology:

function - An object that exposes the [[Call]] internal method. ECMAScript function - A function whose invocation result and side-effects is proved by evaluating ECMAScript code. alien function - A function whose invocation result and side-effects is provided in some manner other than by evaluating ECMAScript code. standard function - a function whose invocation result and side-effects defined by the ECMAScript specification (mostly chapter 15)

An ECMAScript function might be either a mundane or an exotic object. An alien function is always an exotic object because the default [[Call]] internal method produces the invocation result and side-effects by evaluating ECMAScript code. A standard function can potentially be implemented either as an ECMAScript function or an alien function.

I think all of the above terms have places where they are useful in the specification. If some aren't needed they can be dropped.

# Jason Orendorff (13 years ago)

On Mon, Jan 30, 2012 at 11:05 AM, Wes Garland <wes at page.ca> wrote:

So, a good example here would be E4X objects?  (Ignoring that E4X is a standard, let's pretend they are engine vendor bolt-ons).  They have behaviours different from standard ES objects; the first one that pops to mind is that is possible for two E4X objects to be == but not ===.

E4X objects are exotic foreign alien mutants.

# David Bruant (13 years ago)

Le 06/04/2012 21:19, Allen Wirfs-Brock a écrit :

/object/: An runtime entity that has identity and exposes properties (via implementations of the required "internal methods" specified in chapter 8) /mundane object/: An /object/ that that uses only default behaviors for the required internal methods as specified in chapter 8. [and currently elsewhere until I do some reorganizing] /exotic object/: An /object/ that provides non-default behavior for at least one of the required internal methods.

What are arrays? mundane or exotic? Based on the definition, it seems it would be exotic, but it depends on whether you intend to move array internal method definitions to chapter 8.

(...)

Function terminology:

/function -/ An /object/ that exposes the [[Call]] internal method. /ECMAScript function -/ A /function/ whose invocation result and side-effects is proved by evaluating ECMAScript code. /alien function -/ A /function/ whose invocation result and side-effects is provided in some manner other than by evaluating ECMAScript code. /standard function/ - a /function/ whose invocation result and side-effects defined by the ECMAScript specification (mostly chapter 15)

An /ECMAScript function/ might be either a /mundane/ or an /exotic object/. An /alien function/ is always an /exotic object/ because the default [[Call]] internal method produces the invocation result and side-effects by evaluating ECMAScript code. A /standard function/ can potentially be implemented either as an /ECMAScript function/ or an /alien function/.

Currently, parseInt.toString() results in "function parseInt() { [native code] }" on Firefox (and other browsers I think), so it might be more suitable to rename "alien functions" to "native functions" for the sake of consistency.

Thanks for the work on naming and defining things. It's never an easy job.

# Allen Wirfs-Brock (13 years ago)

On Apr 6, 2012, at 2:14 PM, David Bruant wrote:

Le 06/04/2012 21:19, Allen Wirfs-Brock a écrit :

object: An runtime entity that has identity and exposes properties (via implementations of the required "internal methods" specified in chapter 8) mundane object: An object that that uses only default behaviors for the required internal methods as specified in chapter 8. [and currently elsewhere until I do some reorganizing] exotic object: An object that provides non-default behavior for at least one of the required internal methods. What are arrays? mundane or exotic? Based on the definition, it seems it would be exotic, but it depends on whether you intend to move array internal method definitions to chapter 8.

exotic...it only think that I would move into chapter 8 (at least by reference) would be the default definition for thinks like [[Call]] and [[Construct]] that are currently scattered around the specification..

(...)

Function terminology:

function - An object that exposes the [[Call]] internal method. ECMAScript function - A function whose invocation result and side-effects is proved by evaluating ECMAScript code. alien function - A function whose invocation result and side-effects is provided in some manner other than by evaluating ECMAScript code. standard function - a function whose invocation result and side-effects defined by the ECMAScript specification (mostly chapter 15)

An ECMAScript function might be either a mundane or an exotic object. An alien function is always an exotic object because the default [[Call]] internal method produces the invocation result and side-effects by evaluating ECMAScript code. A standard function can potentially be implemented either as an ECMAScript function or an alien function. Currently, parseInt.toString() results in "function parseInt() { [native code] }" on Firefox (and other browsers I think), so it might be more suitable to rename "alien functions" to "native functions" for the sake of consistency.

Yes, but that meaning of "native" is different from the meaning "native" used in ES5 (4.3.6) so is likely to also be confusing. The multiple common meanings of "native" is one reason I avoid that term for this go around.