From: Garrett Smith on 23 Mar 2010 17:07 Asen Bozhilov wrote: > Garrett Smith wrote: >> kangax wrote: > >> A built-in object is native. In ES5, a built-in object can be >> non-standard. Therefore, a native object can be non-standard. > > Therefore: > > var myObj = new Object(); > > is non standard native object? Of course not. Method `atob` is, however, not specified by ECMA-262. Method `atob` is a non-standard object (a function object). I don't think so. ES5 define standard > built-in objects in: "15 Standard Built-in ECMAScript Objects". There > definition of properties and behavior of standard built-in objects. > That section describes the "standard" built-in objects. The non-standard built-in objects are non-standard; not defined by the specification. > | 4.3.7 > | 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. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > From that point, there aren't non standard native objects. That is a statement defines what a built-in object is, it does not define "native object". Conclusions about the limitations of "native object" cannot be made from that statement. The definition of "native object" should state such limitations. There, ECMA-262 states: | Standard native objects are defined in this specification. Some native | objects are built-in; others may be constructed during the course of | execution of an ECMAScript program. The paragraph implicitly allows for non-standard native objects because it does not forbid such objects. A built-in object is "available at the start of the execution of an ECMAScript program". Therefore, a built-in object could never be constructed during the course of execution of a Program. For example of non-standard, native object, a compliant implementation could implement a host DOM Element object as a native object (some do). The DOM Element is not a built-in object because it fails to meet the criteria "independent of the host environment" and fails to meet the criteria "available at the start of the execution of an ECMAScript program". > Implementation can provide non standard built-in objects, which aren't > specified in section 15. If any object isn't native, that object isn't > non-standard native object. It's a host object, from: > > | 4.3.8 > | Any object that is not native is a host object. > I see no contradiction. >> Examples non-standard (native) built-in objects include `atob`, >> `Array.slice`, `String.prototype.trimRight`, and `Enumerator` (JScript). > > These are non standard built-in objects, but are standard native > objects. > > That is how I understand it. If method `atob` is (1) supplied by the ECMAScript implementation, and (2) independent of the host environment, and (3) present at the start of the execution of an ECMAScript program, then it is a built-in object. ES5 says every built-in object is a native object, so `atob` is a native, built-in object that is also non-standard. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Dr J R Stockton on 23 Mar 2010 15:33 In comp.lang.javascript message <addjA5I9A9pLFwMT(a)J.A830F0FF37FB96852AD0 8924D9443D28E23ED5CD>, Mon, 22 Mar 2010 20:17:01, John G Harris <john(a)nospam.demon.co.uk> posted: >On Sun, 21 Mar 2010 at 13:29:22, in comp.lang.javascript, Peter Michaux >wrote: > <snip> >>I think this FAQ entry should be removed. > >I disagree. > ><FAQENTRY> >That said, I think this FAQ topic could do with one or two extra >sentences at the front saying what an Object Model is. The current text >says what it is not, and what it allows you to do, but no more. Agreed. The copious posters here are extremely ready to argue interminably about points of fine detail which are of marginal interest to those for whom the FAQ was written and for whom a FAQ should still be intended. Perhaps there should be two FAQs; one intended to be helpful to the less capable or less well-informed coders, and one intended for the amusement of its contributors. -- (c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME. Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links. Proper <= 4-line sig. separator as above, a line exactly "-- " (RFCs 5536/7) Do not Mail News to me. Before a reply, quote with ">" or "> " (RFCs 5536/7)
From: Garrett Smith on 24 Mar 2010 02:48 Asen Bozhilov wrote: > Garrett Smith wrote: > >> | A host object is an object supplied by the host environment to >> | complete the execution environment of ECMAScript. >> | >> | Examples of Host objects: `document`, `XMLHttpRequest`, and `alert`. > > "Host objects aren't specified by ECMA-262 standard. They are > specifics for different environments. Each ECMA-262 implementation can > provide additional objects. If any of these objects aren't specified > by ECMA-262, it's a host object." > A host object is not specified by ECMA-262. A host object is not part of the ECMAScript implementation, but is exposed to the ECMAScript implementation. A Host object may be implemented as a native ECMAScript object, however this is not required. For example, Internet Explorer, implements many scriptable DOM objects as ActiveX Objects, often resulting in unexpected errors. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Asen Bozhilov on 24 Mar 2010 04:28 Garrett Smith wrote: > Asen Bozhilov wrote: > > | 4.3.7 > > | 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. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > From that point, there aren't non standard native objects. > > That is a statement defines what a built-in object is, it does not > define "native object". Conclusions about the limitations of "native > object" cannot be made from that statement. Definitely. That point define what is "built-in" object. And make definition: "Every built-in object is a native object", which mean. If implementation provide others built-in objects, they are native objects. String.prototype.substr; It's non standard built-in object. When it's built-in object, that mean it's a native object. Object cannot be both non standard built-in and non standard native. If it's non-standard built-in, it's native object. If it's non standard native, it's a host object.
From: Thomas 'PointedEars' Lahn on 24 Mar 2010 05:10
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. Yes, it evidently is. But that does not necessarily make your statement false, see below. > 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. > ^^^^^^^^^^^^ See the part that kangax quoted. What is not clearly specified in ES3F, though, is that a callable host object would need to implement [[Call]], and that, for example, a host object that keeps an internal state would need to have a [[Value]] property (as those properties are not included in the list of mandatory implementations there). ES5 specifies instead that "Every object (including host objects) must implement _all_ of the internal properties listed in Table 8." where the caption of Table 8 is "Table 8 -- Internal Properties Common to All Objects" and includes e.g. [[Call]] and [[Value]], so we can reasonably assume this was an erratum in ES3F. ES5 leaves a bit of confusion here, though, because if every object must implement [[Call]], IsCallable(), which is used in several places, does not make sense (as it would always need to return true). It stands to reason that they meant that every *callable* object must implement [[Call]] (but they should have said so). > Native objects should follow specification in "8.6.2" and if they > differ from that behavior, they are host objects. Think about it. I presume it depends on how you define "differ". "[...], a conforming implementation of ECMAScript is permitted to provide properties not described in this specification, and values for those properties, for objects that are described in this specification." (section 2) 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. However, I find it important to note (although you may be aware of it) that the reverse does not apply: When an object implements those properties and methods as specified, it may still be a host object. 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.) |