From: Garrett Smith on
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
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
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
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
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.)