I suppose a definition of native and built-in objects is required to answer this question. Here's what the ECMAScript spec defines these as:
4.3.6 native object
object in an ECMAScript implementation, independent of the host environment, that is present at the start of
the execution of an ECMAScript program.
NOTE Standard native built-in 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
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.
I'm looking forward to an explanation of this one.
Here is what ES5 shows:
4.3.6
native object # Ⓣ
object in an ECMAScript implementation whose semantics are fully defined by this specification rather than by the host environment.
NOTE 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.
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.
As you can see, it's different that what you've shown.
Built-in objects are native objects made available by the ECMAScript-compliant engine. For example:
String
Object
Array
Undefined
Boolean
etc.
A native object is, for example:
var obj = {};
Or the list shown before. Built-in objects are native.
Also, you didn't show it, but a host object is an object dependant on the environment. For example, in browsers, the host object is window. There are other host objects such as document or XMLHttpRequest though.
Native object - means implemented not in ECMAScript itself. Buiilt-in object - the one that's provided by the engine. Think Math, String and such.
Related
AFAICT ES2015 brings in new nomenclature "intrinsic objects".
Are ES2015+ intrinsic objects equivalent to built-in objects in ES 5.1?
Not exactly, they are a subset of them.
From the spec §6.1.7.4 Well-Known Intrinsic Objects (emphasis mine):
Well-known intrinsics are built-in objects that are explicitly
referenced by the algorithms of this specification and which usually
have Realm
specific identities. Unless otherwise specified each
intrinsic object actually corresponds to a set of similar objects, one
per Realm.
The definition of built-in objects in §4.3.9 built-in object still applies:
object specified and supplied by an ECMAScript implementation
which is really everything not created by the user. See also §17 ECMAScript Standard Built-in Objects.
So there are also many built-in objects that are not intrinsics (e.g. well-known symbols, global objects, methods of intrinsics, methods of other built-in objects).
I've tried to understand ECMAScript 2015 specification in one point: Internal Slots of Objects. But this section appeared very unclear to me, especially this sentence:
Internal slots correspond to internal state that is associated with objects and used by various ECMAScript specification algorithms.
(Does it use correct grammar?) Can anybody explain this notion in English?
What I can understand so far:
internal slots are not properties
internal slots are used during the creation of an object, but not added to the object itself
internal slots are or have values, initially undefined
Summary
Internal slots / methods are pseudo-properties / -methods that the specification uses to define required behavior. ("Abstract operations" are a related mechanism of the spec.) Slots represent state (values), and methods describe algorithms (behavior). They may or may not correspond to properties of objects used by the engine, but they're not available to user code, except as exposed by some part of the public API. The actual implementation an engine uses may be very different from what the internal methods sketch out, but to be compliant they have to produce behavior or results that are consistent with the internal methods.
Examples
[[StringData]] internal slot
The behavior of String, e.g. new String("whatever"), is described in terms that include a [[StringData]] internal slot that represents the value (whatever in this case). The internal slot isn't directly accessible to user code, but String.prototype.toString() (e.g. (new String("whatever")).toString()) is defined in terms of a thisStringValue() abstract operation, which is described in terms of returning the value of [[StringData]]. So in other words, String.prototype.toString() is public API that is essentially a getter that exposes [[StringData]].
[[OwnPropertyKeys]] internal method
The behavior of Object.keys() is described in terms that include calling the [[OwnPropertyKeys]] internal method. Note that different kinds of objects, such as ordinary objects (e.g. Object) and exotic objects (e.g. String) may have different definitions of [[OwnPropertyKeys]]. When [[OwnPropertyKeys]] is "called" in the spec, that refers to the definition for the applicable type. There are also some invariant characteristics that apply to its definition for any object type.
It's simply an artifice used to be able to describe precisely how the objects should behave.
They are not real members of the objects and even if in some implementation they are you are not allowed to access them with portable code.
In other words it's a way to write the specification that allows describing behavior with imperative code that is formally more precise that just using a wordy "natural-language" description of what the behavior should be.
In terms of the language what do I get back when I grab an element from the DOM as such:
var obj = document.getElementById('foo');
It has properties, so I thought that maybe it might be an object literal. Using type checks I determined that it is not an object literal, it is also not an array literal.
I know what it is used for, and how to use it, just not what it is, technically speaking in terms of the language.
I ran it through this test which I call a test for an abstract object.
obj === Object(obj);
which it returned false.
I know that I can identify node elements as such
obj.nodeType === 1
but still this doesn't tell me what it is, in terms of the language (ES5). What is an element expressed in terms of the language?
Clarification
I mean the language, based on a grammar, JavaScript, the Good
Parts, Chapter 2, This grammar only knows how to deal with language
components, arrays, objects, etc.
Element is not defined in terms of ES5. It is a part of the DOM API.
Here is its definition
The Element interface represents an element in an HTML or XML document.
A language does not have to implement the ES5 specification to implement the DOM API interface, moreover - ES5 implementations can be valid and not implement Element. For example, NodeJS does server side JavaScript and does not implement Element.
In terms of the ECMAScript specification, DOM Elements are "host objects" provided by the browser's host environment (emphasis mine below):
ECMAScript as defined here is not intended to be computationally self-sufficient; indeed, there are no provisions in this specification for input of external data or output of computed results. Instead, it is expected that the computational environment of an ECMAScript program will provide not only the objects and other facilities described in this specification but also certain environment-specific host objects, whose description and behaviour are beyond the scope of this specification except to indicate that they may provide certain properties that can be accessed and certain functions that can be called from an ECMAScript program.
The particular properties of DOM elements are specified by the interfaces laid out in the W3C's DOM specification, not by the ECMAScript spec (although the ECMAScript spec allows for them to exist, by allowing for environment-supplied host objects).
Addendum:
You have added some clarification that your confusion stems from the fact that JavaScript uses a grammar. I'm having a hard time understanding why that causes confusion for you, but I'll try to clear things up.
JavaScript's grammar is lexical, i.e., it deals with written code. That written code is parsed (using a grammar) and the parser identifies particular expressions in the code. Those expression correspond to programmatic operations in the execution environment.
The grammar that is used to refer to a host object is identical to the grammar used to refer to a native object. In fact, a host object is an object. The only difference is that a host object can specify the behavior of its internal methods, like [[Get]] (used for property access).
I am currently learning advanced JavaScript, with an aim to build a standards compliant (HTML5, CSS3, ESv5) library. Along my way I have already asked a couple of related questions to try and figure out where to start, what to do, what not to do, what to avoid etc. I have already begun reading the ECMA-262 (ECMAScript version 5) documentation, and have been running a few tests before I get started on development work.
Previous questions:
Writing ECMAScript5 compliant code
What's the difference between JavaScript, JScript & ECMAScript?
In my research I found out that different browsers implement the standard differently, and in that respect, they implement different objects. For example, IE implements an object called ActiveXObject, but this is not the case in FireFox. So I wrote a little test facility which determines if something is defined within the browser.
Consider the following which tests a few known objects (including jQuery since this is not built in).
Again, I have reached a point where I am in need of help:
Questions:
Given the example above, what is the difference between an object and a function?
Do I write functions or objects in ES/JS?
Why is Object a function and not an object?
Is there any hierarchical structure to built in objects / functions?
Can built in objects / functions be redefined as something entirely different?
Can built in objects / functions be undefined?
Can built in objects / functions be assigned new features if they do not already support them natively?
If an object is defined in one browser and not another, how can I compensate for this?
P.S. I do not want answers relating to specific implementations (JavaScript/JScript), rather answers relating to the standard (ECMAScript v5). Thanks in advance!
Given the example above, what is the difference between an object and a function?
In Chrome, all these items are functions. In general however, a function is an object with the addition that it holds code and that you can call it. So, you can also just add properties to functions (like jQuery does: $("selector") or $.ajax).
Do I write functions or objects in ES/JS?
Well, obviously that depends on what you code. function() {} gives you a function; {} gives you an object. (Again, functions are objects in the end.)
Why is Object a function and not an object?
Object is a function because you can call it, either as a constructor or not:
Object(); // returns an empty object
new Object(); // same
Also, given that almost everything is an instance of Object, it follows that Object is a constructor and thus a function. (Note again that functions are also objects.)
Is there any hierarchical structure to built in objects / functions?
As for the ECMAScript built-in objects, there is in a sense. There are constructor functions (String) on the global object, functions for instances (Array.prototype.forEach), and "static" functions (Object.defineProperty which is meant to be used on objects, Array.isArray for arrays).
Can built in objects / functions be redefined as something entirely different?
Sure, you can do Object = null. But any code relying on Object will start throwing exceptions, so it's not recommended at all.
Can built in objects / functions be undefined?
No, an object is not undefined by definition. undefined is not an object and vice-versa. This holds for any object.
Can built in objects / functions be assigned new features if they do not already support them natively?
Yes, if e.g. Array.prototype.forEach does not exist, you could set it yourself. But it should be noted that such functions turn up in for(var key in arr) loops which again can cause code to behave differently. This can be solved using Object.defineProperty by using {enumerable: false}. But there is another caveat: the function is shared across the whole environment (e.g. the current page). If other code is also setting them you're experiencing collisions.
If an object is defined in one browser and not another, how can I compensate for this?
You can "shim" such functions. For e.g. ES5 functions such as Array.prototype.forEach there are shims available which make them available on older browsers as well. Underscore.js may be a good example.
Given the example above, what is the difference between an object and a function?
A function is just an object which is callable. However, I guess you ask for the types of host objects (Node, HTMLCollection etc): Their behaviour is implementation-dependent ("not ecmascript-native") - you can't rely on anything.
Do I write functions or objects in ES/JS?
Huh? You write code, which can be interpreted.
Why is Object a function and not an object?
Object is the native object constructor, and therefore a function (and also an Object).
Is there any hierarchical structure to built in objects / functions?
Do you ask for "Everything is an Object"? If you ask for the structure of DOM interfaces: They are implementation-dependent host objects again, but most implementors have a inheritance system based on the DOM specification.
Can built in objects / functions be redefined as something entirely different? Can built in objects / functions be undefined?
No. You can overwrite the global variables pointing to them (the properties of the global object), but every instance will nevertheless be constructed from the native (then [nearly] unaccessible) constructors.
Can built in objects / functions be assigned new features if they do not already support them natively? If an object is defined in one browser and not another, how can I compensate for this?
Yes, you can extend the native objects and their prototypes. But watch out for host objects, they might not like it. If an object is defined only in certain environments, you can easily test for its existance and possibly shim it (es5, html5).
As part of my research into ECMAScript / JavaScript, I have found the following resource which provides a lot of information regarding the JS DOM.
http://krook.org/jsdom/index-all.html
I don't understand the difference between native objects and host objects in JavaScript. Does the latter simply refer to non-primitive function objects that were created by a custom constructor (e.g., var bird1 = new Bird();)?
Both terms are defined in the ECMAScript specification:
native object
object in an ECMAScript implementation whose semantics are fully
defined by this specification rather than by the host environment.
NOTE 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.
Source: http://es5.github.com/#x4.3.6
host object
object supplied by the host environment to complete the
execution environment of ECMAScript.
NOTE Any object that is not native is a host object.
Source: http://es5.github.com/#x4.3.8
A few examples:
Native objects: Object (constructor), Date, Math, parseInt, eval, string methods like indexOf and replace, array methods, ...
Host objects (assuming browser environment): window, document, location, history, XMLHttpRequest, setTimeout, getElementsByTagName, querySelectorAll, ...
It is more clear if we distinguish between three kinds of objects:
Built-in objects: String, Math, RegExp, Object, Function etc. - core predefined objects always available in JavaScript. Defined in the ECMAScript spec.
Host objects: objects like window, XmlHttpRequest, DOM nodes and so on, which is provided by the browser environment. They are distinct from the built-in objects because not all environment will have the same host objects. If JavaScript runs outside of the browser, for example as server side scripting language like in Node.js, different host objects will be available.
User objects: objects defined in JavaScript code. So 'Bird' in your example would be a user object.
The JavaScript spec groups built-in objects and user objects together as native objects. This is an unorthodox use of the term "native", since user objects are obviously implemented in JavaScript while the built-ins is most likely implemented in a different language under the hood, just as the host objects would be. But from the perspective of the JavaScript spec, both builtins and user objects are native to JavaScript because they are defined in the JavaScript spec, while host objects are not.
Here's my understanding of the spec.
This:
var bird = new Bird();
...results in a native Object that simply happened to be created using the new operator.
Native objects have an internal [[Class]] property of one of the following:
"Arguments", "Array", "Boolean", "Date", "Error", "Function", "JSON", "Math", "Number", "Object", "RegExp", and "String".
For your bird1 it will be:
"Object"
Just like if you create a function:
function my_func() {
// ...
}
...my_func isn't defined in ECMAScript, but it is still a native object with the internal [[Class]]:
"Function"
A host object is an object provided by the environment in order to serve a specific purpose to that environment not defined in by the specification.
For example:
var divs = document.getElementsByTagName('div')
The object referenced by divs is a NodeList, which is integrated into the environment in such a manner that it feels like a regular JavaScript object, yet it isn't defined anywhere by the specification.
Its internal [[Class]] property is:
"NodeList"
This provides implementation designers some flexibility in suiting the implementation to the specific need of the environment.
There are requirements of host objects that are defined throughout the spec.
In addition to the other answers regarding Host Objects.
Host objects are specific to a environment. So next to the browsers' host objects, there are also specific objects in nodejs.
For the sake of the example, first starting with the Standard objects as defined in Javascript. Then the common objects for the Browser/DOM. Node has it's own Objects.
Standard Javascript built-in object examples:
Object
Function
Boolean
Symbol
Number
Math
... (See full list on MDN web docs)
Host Objects Document Object Model Examples:
Window
Document
History
... (See full list on DOM objects on MDN web docs)
XMLHttpRequest (part of Web API)
... (See full list Web API on MDN web docs)
Host Objects in Node.js:
http
https
fs
url
os
... (See full list on nodejs.org)
Could not see a convincing answer to the question whether var bird1 = new Bird(); is a native or host object. Assuming Bird is a user defined function, a native non-built-in object will be created according to http://es5.github.io/#x13.2 by the javascript implementation. In contrast, native built-in objects will be present since the start of a javascript program (such as Object and many others). A difference between a native object and a host object is that former is created by the javascript implementation and the latter is provided by the host environment. As a result host object internal [[class]] property can be different from those used by built-in objects (i.e. "Arguments", "Array", "Boolean", "Date", "Error", "Function", "JSON", "Math", "Number", "Object", "RegExp", and "String").
Also, worthwhile noting that ECMA6 http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf does not use the terminology native and host objects any more. Instead, it defines below object types, with more clear explanations of their intended behaviour.
4.3.6 ordinary object
object that has the default behaviour for the essential internal methods that must be supported by all objects
4.3.7 exotic object
object that does not have the default behaviour for one or more of the essential internal methods that must be supported by all objects
NOTE
Any object that is not an ordinary object is an exotic object.
4.3.8 standard object
object whose semantics are defined by this specification
4.3.9 built-in object
object specified and supplied by an ECMAScript implementation
Considering three objects: Host, Native, Custom.
Host Objects are created by the environment and are environment specific. Best known environment would be a web-browser but could be another platform. The host objects created in web-browser could be the window object or the document. Typically a browser uses an API to create Host Objects to reflect the Document Object Model into JavaScript. (Webbrowser have different JavaScript Engines that do this) A host object is created automatically the moment the page renders in a browser.
A Native Object is created by the developer using predefined classes of JavaScript. Native Objects are in your written script.
Than, a Custom Object is made by the developer from a custom (not predefined, or partially predefined) class.
Native objects are objects that adhere to the specs, i.e. "standard objects".
Host objects are objects that the browser (or other runtime environment like Node) provides.
Most host objects are native objects, and whenever you instantiate something using new, you can be 99.99% sure that it is a native object, unless you mess around with weird host objects.
This notion has been introduced due to the presence of very bizarre objects in IE(and other old browsers?). For example:
typeof document.all == "undefined"; // true
document.all.myElementId; // object
When seeing this, everyone would agree that document.all is clearly "non-standard", and thus a non-native host object.
So why not call native objects standard objects in the first place? Simple: after all, the Standard(!) document talks about non-native objects too, and calling them non-standard would lead to a paradox.
Again:
native == "standard"
host == provided by the browser or Node or …
most host objects are native, and all non-host objects are native too
This may be overkill, but for simplicity a native object is one that exist and is usable in any environment that implements an ECMAScript compliant engine. This is usually (but not always) a browser.
So, your Internet Explorer or your Google Chrome, doesn't make the String object available to you, for example. The reason you can use the String object is because it is "native" (built-in) to the JavaScript language itself.
However, if you'd like to create a pop-up window, you'll need to use the window object. The window object is provided by the browser software itself, so it is not native to JavaScript, but it is part of the "Browser Object Model" or the BOM.