FAQ Topic - What are object models? (2010-03-21)
in [JavaScript]
|
From: Thomas 'PointedEars' Lahn on 24 Mar 2010 05:16 Thomas 'PointedEars' Lahn wrote: > Asen Bozhilov wrote: >> Native objects should follow specification in "8.6.2" and if they >> differ from that behavior, they are host objects. Think about it. > > [...] > If by "behavior" you were only referring to the implementations specified > in 8.6.2, and not the set of internal properties and methods as the basis > for difference, then your logic is sound, and I stand corrected. It should be noted that the logic is only sound in that context if it is understood as "Native objects shall/must follow specification in "8.6.2" and if they differ from that behavior, they are host objects." The difference between "shall/must" and "should" is the difference between an absolute requirement and a recommendation. PointedEars -- Use any version of Microsoft Frontpage to create your site. (This won't prevent people from viewing your source, but no one will want to steal it.) -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
From: Thomas 'PointedEars' Lahn on 24 Mar 2010 05:34 kangax wrote: > Asen Bozhilov wrote: >> Thomas 'PointedEars' Lahn wrote: >>> What is true is that host objects *do* *not* *need* *to* implement the >>> internal properties and methods as their specified algorithms describe, >>> but they do need to implement those properties and methods (8.6.2), and >>> they MAY implement them as specified. >> >> It's not true. Specification is completely about this case: >> >> | 8.6.2 >> | The following table summarises the internal properties >> | used by this specification. The description indicates their >> | behaviour for native ECMAScript objects. >> | Host objects may implement these internal methods with any >> | implementation-dependent behaviour, or it may be >> | that a host object implements only some internal methods and >> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> | not others. >> ^^^^^^^^^^^^ > > But look further ;) > > "Every object (including host objects) must implement the [[Prototype]] > and [[Class]] properties and the [[Get]], [[Put]], [[CanPut]], > [[HasProperty]], [[Delete]], and [[DefaultValue]] methods. (Note, > however, that the [[DefaultValue]] method may, for some objects, simply > throw a TypeError exception.)" Exactly. But see my other followups. >> Native objects should follow specification in "8.6.2" and if they >> differ from that behavior, they are host objects. Think about it. > > I see what you mean about non-specified behavior and host objects. > > The problem here, as I see it, is that ES3 and ES5 differ in > explanations of what host objects are. ES3 basically says that host > object is anything that's not a native object, where native object is > "[...] any object *supplied* by an ECMAScript implementation". "... independent of the host environment." I fail to see the difference. > It's not clear if "supplied" refers to *binding* (which is what I > emphasized on) or *behavior*/*semantics* (which is what you emphasized > on). It is very clear to me that it doesn't refer to binding. > To muddy the water even more, ES3 goes on to bring "standard" word into > the picture — saying "*Standard* native objects are defined in this > specification", implying that there could be *non-standard* native > objects. It is very clear to me that standard built-in/native¹ objects are those defined in the language standard: Object, String, Number aso: | NOTE Standard native objects are defined in this specification. | [...] | NOTE Standard built-in objects are defined in this specification, [...] | Every built-in object is a native object. [...] > Now, ES5 rewords slightly what "native object" means: "[...] object in > an ECMAScript implementation whose semantics are fully defined by this > specification rather than by the host environment.". So now there's > "semantics", which wasn't there before (and which could well be a > clarification on what ES3 failed to mention). But again, a note > following that definition confuses the matters with "*standard* native > object". I don't think so, see above. > What's strange to me about your definition, is that ES5 only indirectly > defines host objects as something, semantics of which is not defined in > specs. The opposite of "fully defined by this specification" is "not *fully* defined by this specification". It is not "not defined by this specification (at all)". > 4.3.8 clearly focuses on where/what defines an object, saying > that host object is "object supplied by the host environment to complete > the execution environment of ECMAScript." So? > Another problem with saying "host object is an object semantics of which > is not defined in specs", is that it's easy to confuse semantics with ^^^^^^^^^^^^^^^^^^^^^^^ > binding (at least I did); so when giving this kind of explanation it > might make sense to emphasize that it's not "binding" we are talking > about. Perhaps give explaining example too. Non sequitur, see above. > I'll bring this on ES5-discuss mailing list when/if I get chance. You should double-check your logic module first as I needed to double-check mine :) HTH PointedEars -- Use any version of Microsoft Frontpage to create your site. (This won't prevent people from viewing your source, but no one will want to steal it.) -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
From: Thomas 'PointedEars' Lahn on 24 Mar 2010 05:52 Garrett Smith wrote: > kangax wrote: >> On 3/22/10 10:50 AM, Asen Bozhilov wrote: >>> kangax wrote: >>>> 4.3.6 also says: >>>> "A native object is any object supplied by an ECMAScript >>>> implementation independent of the host environment. Standard native >>>> ^^^^^^^^^^^^^^^ >>>> objects are defined in this specification." >>>> ^^^^^^^ >>>> >>>> ...implying that there could be other (not "standard") native objects. >>> >>> If it's non standard "native" object will be a host object: No. >>> | ECMA-262-3 >>> | 4.3.8 Host Object >>> | A host object is any object supplied by the host environment >>> | to complete the execution environment of >>> | ECMAScript. Any object that is not native is a host object. >> >> Yes, if it's not native it's host object. But if it's not native >> *standard*, it could just be native *non-standard*; i.e. it's provided >> by implementation (not host environment), but is not part of ECMA-262 >> specification. > > A built-in object is native. In ES5, a built-in object can be > non-standard. Therefore, a native object can be non-standard. > > ES5, s 4.3.7 > | built-in object > | object supplied by an ECMAScript implementation, independent of the > | host environment, that is present at the start of the execution of an > | ECMAScript program. > | > | NOTE Standard built-in objects are defined in this specification, and > | an ECMAScript implementation may specify and define others. Every > | built-in object is a native object. A built-in constructor is a > | built-in object that is also a constructor. > > This definition of built-in has the effect of differentiating between > things that are part of the ecmascript implementation from objects that > are made available by the host environment. No. It has the effect of differentiating between things that are defined in the ECMAScript Specification and things that are provided by the ECMAScript implementation. > Examples non-standard (native) built-in objects include `atob`, > `Array.slice`, `String.prototype.trimRight`, and `Enumerator` (JScript). But those are not host objects. Only objects that are provided by the host environment are host objects. The host environment is not the same as the language implementation. > A host object may be implemented as a native object. No, absolutely not. | NOTE Any object that is not native is a host object. > For example, XMLHttpRequest. From the definitions it follows that this can either be/refer to a built-in object (which would justify MS's statement of "native"), or a host object. > This does not, however, make that host object built-in. True. No host object can ever be a built-in object. An image says more than a thousand words: ,---------------------------------------------------------. | objects | | ,-----------------------------. ,--------------------. | | | native | | host | | | | ,-------------------------. | | | | | | | built-in | | | | | | | | ,---------------------. | | | | | | | | | standard built-in/ | | | | | | | | | | standard native | | | | | | | | | `---------------------' | | | | | | | `-------------------------' | | | | | `-----------------------------' `--------------------' | `---------------------------------------------------------' >>> ES5 has better definition of native objects: >>> >>> | ECMA-262-5 >>> | 4.3.6 >>> | native object >>> | object in an ECMAScript implementation whose semantics are >>> | fully defined by this specification rather than by >>> | the host environment. >> >> That's why I mentioned vagueness. Specs seem to be confused on the >> distinction of host objects and native non-standard objects. > > AIUI, "semantics" is regarding section 8.6. The semantics describe what > happens when applying the call operator to `String.prototype.trimRight` > (e.g. call the [[Call]] property), but do not explain what that method > will do (throw error, etc). ACK > [...] >> >>> If `Foo` refer object, which semantic is defined by ECMA-262 >>> standard that mean, `Foo` refer native object. >> >> So you say that object referenced originally by >> `Array.prototype.forEach` (which is not defined in ECMA-262, but is >> present in, say, Mozilla's Spidermonkey implementation) is a host >> object? > > `Array.prototype.forEach` fits the definition of built-in object. ACK PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Asen Bozhilov on 24 Mar 2010 05:54 Thomas 'PointedEars' Lahn wrote: > If by "behavior" you were only referring to the implementations specified > in 8.6.2, and not the set of internal properties and methods as the basis > for difference, then your logic is sound, and I stand corrected. The behaviour of internal properties and methods of native objects are defined explicitly in specification. If object has behaviour, which standard doesn't describe in explicit way in 8.6.2. That is a host object. See quotations: | ECMA-262 5 edition: | 8.6.2 | Object Internal Properties and Methods | This specification uses various internal properties | to define the semantics of object values. | The Table 8 summarises the internal properties used | by this specification that are applicable to all | ECMAScript objects. The Table 9 summarises the internal | properties used by this specification that are only | applicable to some ECMAScript objects. The descriptions | in these tables indicates their behaviour for native | ECMAScript objects, unless stated otherwise in this document | for particular kinds of native ECMAScript objects. Host objects | may support these internal properties with any | implementation-dependent behaviour as long as it is consistent with the | specific host object restrictions stated in this document. | Host objects may implement these internal methods in | any manner unless specified otherwise; for example, | one possibility is that [[Get]] and [[Put]] for a particular | host object indeed fetch and store property values but | [[HasProperty]] always generates false.
From: Thomas 'PointedEars' Lahn on 24 Mar 2010 07:00
Thomas 'PointedEars' Lahn wrote: > Garrett Smith wrote: >> ES5, s 4.3.7 >> | built-in object >> | object supplied by an ECMAScript implementation, independent of the >> | host environment, that is present at the start of the execution of an >> | ECMAScript program. >> | >> | NOTE Standard built-in objects are defined in this specification, and >> | an ECMAScript implementation may specify and define others. Every >> | built-in object is a native object. A built-in constructor is a >> | built-in object that is also a constructor. >> >> This definition of built-in has the effect of differentiating between >> things that are part of the ecmascript implementation from objects that >> are made available by the host environment. > > No. It has the effect of differentiating between things that are defined > in the ECMAScript Specification and things that are provided by the > ECMAScript implementation. Please ignore that, you are evidently right in *this* instance. > [...] > ,---------------------------------------------------------. > | objects | > | ,-----------------------------. ,--------------------. | > | | native | | host | | > | | ,-------------------------. | | | | > | | | built-in | | | | | > | | | ,---------------------. | | | | | > | | | | standard built-in/ | | | | | | > | | | | standard native | | | | | | > | | | `---------------------' | | | | | > | | `-------------------------' | | | | > | `-----------------------------' `--------------------' | > `---------------------------------------------------------' PointedEars -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004) |