Re: Let's kill terms native and host
On Mon, Jan 30, 2012 at 11:05 AM, Wes Garland w...@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. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms native and host
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.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms native and host
2012/1/30 Brendan Eich bren...@mozilla.org Andreas Rossberg wrote: On 30 January 2012 20:17, Oliver Huntoli...@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 http://wiki.ecmascript.org/doku.php?id=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 http://wiki.ecmascript.org/doku.php?id=harmony:proto_climbing_refactoring. Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms native and host
On 31 January 2012 12:40, Tom Van Cutsem tomvc...@gmail.com wrote: 2012/1/30 Brendan Eich bren...@mozilla.org Andreas Rossberg wrote: On 30 January 2012 20:17, Oliver Huntoli...@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. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms native and host
On 29 January 2012 20:25, Allen Wirfs-Brock al...@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?). /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms native and host
On 29 January 2012 20:25, Allen Wirfs-Brock al...@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. Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms native and host
On Jan 30, 2012, at 2:10 AM, Andreas Rossberg wrote: On 29 January 2012 20:25, Allen Wirfs-Brock al...@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. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms native and host
On 30 January 2012 11:56, Allen Wirfs-Brock al...@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 ===. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms native and host
On Jan 30, 2012, at 9:05 AM, Wes Garland wrote: On 30 January 2012 11:56, Allen Wirfs-Brock al...@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. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms native and host
On Sun, Jan 29, 2012 at 1:25 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: 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 erig...@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 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms native and host
On Jan 30, 2012, at 10:19 AM, Mark S. Miller wrote: On Sun, Jan 29, 2012 at 1:25 PM, Allen Wirfs-Brock al...@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. Allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms native and host
Mark S. Miller mailto:erig...@google.com January 30, 2012 10:19 AM On Sun, Jan 29, 2012 at 1:25 PM, Allen Wirfs-Brock al...@wirfs-brock.com mailto:al...@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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms native and host
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. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms native and host
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. 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 :( --Oliver /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms native and host
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 http://wiki.ecmascript.org/doku.php?id=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. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms native and host
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! --Oliver ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms native and host
Andreas Rossberg wrote: On 30 January 2012 20:17, Oliver Huntoli...@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. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms native and host
On 28 January 2012 22:51, Mark S. Miller erig...@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* Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms native and host
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 erig...@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 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms native and host
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. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Let's kill terms native and host
[new subject line] On Sat, Jan 28, 2012 at 12:03 PM, Dmitry Soshnikov dmitry.soshni...@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. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms native and host
On Sat, Jan 28, 2012 at 2:27 PM, John-David Dalton
john.david.dal...@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.
http://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.
Seems like the `opera` object falls into that description. I mean it
could be a built-in if supplied by the ECMAScript environment but
that's beside the point. I really just want the wiggle room that ES5.x
provides for [[Class]]/flags/tags/brands.
-JDD
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms native and host
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. +∞! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
