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

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

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 inter

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

On Mon, Jan 30, 2012 at 11:05 AM, Wes Garland 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 possibl

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

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

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

On 31 January 2012 12:40, Tom Van Cutsem wrote: > 2012/1/30 Brendan Eich >> Andreas Rossberg wrote: >>> On 30 January 2012 20:17, Oliver Hunt  wrote: > From the PoV of JSC I suspect our biggest problem will actually be > our API, which essentially allows developers to override an arbitr

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

2012/1/30 Brendan Eich > Andreas Rossberg wrote: > >> On 30 January 2012 20:17, Oliver Hunt 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]] meth

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

Andreas Rossberg wrote: On 30 January 2012 20:17, Oliver Hunt 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 fac

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

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

On 30 January 2012 20:17, Oliver Hunt 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 y

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 ob

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 f

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 ge

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

Mark S. Miller January 30, 2012 10:19 AM On Sun, Jan 29, 2012 at 1:25 PM, Allen Wirfs-Brock 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 t

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

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

On Sun, Jan 29, 2012 at 1:25 PM, Allen Wirfs-Brock 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 > speci

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 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 an

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

On 30 January 2012 11:56, Allen Wirfs-Brock 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 ECMA

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 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 ob

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

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

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

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

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 so

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 mea

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

On 28 January 2012 22:51, Mark S. Miller 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 en

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

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 cor

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 fami