Posts in: es6-spec

Object Property Attributes

ES6 Language Specification Property Attributes

The spec makes a distinction between 2 types of object properties: data properties and accessor properties. Most people are very familiar with the basics of data properties but less familiar with the powerful accessor properties. This post will discuss both.

Data properties are the typical properties that users define on objects while accessor properties are a unique way to set and get those properties from outside the function. For instance here’s some code that sums up which are which:

Data properties have 4 special attributes that are built into Javascript: Value, Writable, Enumerable, and Configurable. Let’s run through each of these.

The first attribute to discuss for data properties is ValueIn short, the spec says that this is the value retrieved by a Get access of the property. Building off of the previous code snippet, here’s an example of its use:

The second built in attribute for data properties is the Writable attribute. This attribute when false will prevent the accessor properties’ Set attribute from working. In other words in the following snippet setting firstName through the Set attribute will not change its value…

The third built in attribute for data properties is the Enumerable attribute. There are a number of built-in functions that either ignore or don’t ignore non-enumerable items. Setting Enumerable to false will mask those items for the functions that ignore them.  Enumeration is quite idiosyncratic as some functions will hide it and others won’t. It’s important to note that when using Object.defineProperty() the default is non-enumerable, but when using a standard object declaration then the default is enumerable. This can lead to some confusion or bugs and is therefore helpful to be aware of. The common use case for setting enumeration to false is to hide it from the for-in loop, however, you should be aware that this property can still be accessed through other functions as you will see in the following snippet. The following snippet lists functions that ignore or include non-enumerable items…

The fourth and final built in attribute for data properties is the Configurable attribute. When this is set to false then it isn’t possible to delete the property or change its attributes. The only exceptions are that the Value attribute may be modified (assuming Writable is true) and that Writable may be switched to false (but not vis-versa).

The defaults for Writable, Enumerable, and Configurable are true in the standard form of object declaration. However, when using property descriptors the defaults are false. The following code snippet demonstrates this…

Accessor properties have 4 special attributes that are built into Javascript: Get, Set, Enumerable, and Configurable. The first 2 we have already seen examples of in the first snippet. The last 2, Enumerable and Configurable, have the same effect as they have with data properties. The defaults for Get and Set are undefined.

All of this said, the following are the relevant portions of the spec:


An Object is logically a collection of properties. Each property is either a data property, or an accessor property:

  • A data property associates a key value with an ECMAScript language value and a set of Boolean attributes.
  • An accessor property associates a key value with one or two accessor functions, and a set of Boolean attributes. The accessor functions are used to store or retrieve an ECMAScript language value that is associated with the property.

Attributes are used in this specification to define and explain the state of Object properties. A data property associates a key value with the attributes listed in Table 2.

Table 2 — Attributes of a Data Property
Attribute Name Value Domain Description
[[Value]] Any ECMAScript language type The value retrieved by a get access of the property.
[[Writable]] Boolean If false, attempts by ECMAScript code to change the property’s [[Value]] attribute using [[Set]] will not succeed.
[[Enumerable]] Boolean If true, the property will be enumerated by a for-in enumeration (see 13.7.5). Otherwise, the property is said to be non-enumerable.
[[Configurable]] Boolean If false, attempts to delete the property, change the property to be an accessor property, or change its attributes (other than [[Value]], or changing [[Writable]] to false) will fail.


An accessor property associates a key value with the attributes listed in Table 3.

Table 3 — Attributes of an Accessor Property
Attribute Name Value Domain Description
[[Get]] Object | Undefined If the value is an Object it must be a function object. The function’s [[Call]] internal method (Table 6) is called with an empty arguments list to retrieve the property value each time a get access of the property is performed.
[[Set]] Object | Undefined If the value is an Object it must be a function object. The function’s [[Call]] internal method (Table 6) is called with an arguments list containing the assigned value as its sole argument each time a set access of the property is performed. The effect of a property’s [[Set]] internal method may, but is not required to, have an effect on the value returned by subsequent calls to the property’s [[Get]] internal method.
[[Enumerable]] Boolean If true, the property is to be enumerated by a for-in enumeration (see 13.7.5). Otherwise, the property is said to be non-enumerable.
[[Configurable]] Boolean If false, attempts to delete the property, change the property to be a data property, or change its attributes will fail.


If the initial values of a property’s attributes are not explicitly specified by this specification, the default value defined in Table 4 is used.

Table 4 — Default Attribute Values
Attribute Name Default Value
[[Value]] undefined
[[Get]] undefined
[[Set]] undefined
[[Writable]] false
[[Enumerable]] false
[[Configurable]] false

The Numeric String Grammar

ES6 Language Specification

5.1.3 The Numeric String Grammar

There is a separate grammar used for converting Strings to numbers. It’s very similar to the lexical grammar in that it’s terminals are SourceCharacters or in other words Unicode characters. There’s really not much to say on this other than it is considered separate from the lexical grammar. It is not clear to me why we need to single this out into its own grammar, so if someone has an idea to why this is necessary then please comment below.

Another grammar is used for translating Strings into numeric values. This grammar is similar to the part of the lexical grammar having to do with numeric literals and has as its terminal symbols SourceCharacter. This grammar appears in

Productions of the numeric string grammar are distinguished by having three colons “:::” as punctuation.

An interesting thing to note between this spec and ES5 is that ES6 has dropped the JSON Grammar defined in section 5.1.5 of the ES5 spec. I’m assuming this is because the JSON has made its way into ECMA-404

The Lexical and RegExp Grammars

ES6 Language Specification

5.1.2  The Lexical and RegExp Grammars

What is the lexical grammar?

The lexical grammar is the most rudimentary part of a grammar’s syntax. It is better described in section 11 of the specs, however, we will briefly describe it here, and leave some of the more intricate details to when we discuss section 11.

We will first quote the spec as a point of reference and then describe it in simpler language. The first paragraph states:

A lexical grammar for ECMAScript is given in clause 11. This grammar has as its terminal symbols Unicode code points that conform to the rules for SourceCharacter defined in 10.1. It defines a set of productions, starting from the goal symbol InputElementDiv, InputElementTemplateTail, or InputElementRegExp, or InputElementRegExpOrTemplateTail, that describe how sequences of such code points are translated into a sequence of input elements.

To better understand what the lexical grammar is we need to cover some of the terminology. The characters that make up the lexical grammar are called SourceCharacters, which are defined as being any Unicode character/symbol. These characters in turn define the lexical productions labeled InputElementDiv, InputElementTemplateTail, InputElementRegExp, and InputElementRegExpOrTemplateTail. These 4 productions are composed of what are termed tokens which are words like while or for or characters like ( or +, as well as non-tokens such as line terminators, comments, and white space. We have 4 distinct productions because each of these have additional valid grammars such as regular expressions or additional punctuators. These 4 productions are used in different contexts within the spec. 

We can now better understand the remaining part of 5.1.2:

Input elements other than white space and comments form the terminal symbols for the syntactic grammar for ECMAScript and are called ECMAScript tokens. These tokens are the reserved words, identifiers, literals, and punctuators of the ECMAScript language.

Moreover, line terminators, although not considered to be tokens, also become part of the stream of input elements and guide the process of automatic semicolon insertion (11.9). Simple white space and single-line comments are discarded and do not appear in the stream of input elements for the syntactic grammar. A MultiLineComment (that is, a comment of the form /**/regardless of whether it spans more than one line) is likewise simply discarded if it contains no line terminator; but if a MultiLineComment contains one or more line terminators, then it is replaced by a single line terminator, which becomes part of the stream of input elements for the syntactic grammar.

A RegExp grammar for ECMAScript is given in 21.2.1. This grammar also has as its terminal symbols the code points as defined by SourceCharacter. It defines a set of productions, starting from the goal symbol Pattern, that describe how sequences of code points are translated into regular expression patterns.

Productions of the lexical and RegExp grammars are distinguished by having two colons “::” as separating punctuation. The lexical and RegExp grammars share some productions.


Context-Free Grammars

ES6 Language Specification

5.1.1 Context-Free Grammars

In order to understand much of the specification moving forward, we will need to understand some basic information on grammar used to describe programming languages. Indeed the spec itself devotes all of section 5 to the basic notation and grammar used in the rest of the documentation. Unfortunately for some, the writers assume familiarity with some aspects of language theory. In order to bridge the gap for those that are not familiar with some of the terminology, and as a refresher for those that are, we will discuss the concepts as they appear.

The first concept to understand is what a context-free grammar is, as it lays the foundation of much of the remaining specification.

Let’s start with an example of a context-free grammar so we have something to reference while we discuss the topic:

Syntactically, each rule here appears as a line. The left-hand side is a single non-terminal (another word for a variable). The right-hand side is a string that consists of any number of terminals (constants) and non-terminals (variables). In our example, 0, 1, and @ are terminals, and A and B are non-terminals. The notation for the non-terminals (variables) is a capital letter or a word that is camel-cased. Terminals (constants) are written in lowercase, or as a number, or a symbol.

Formal grammars have a recursive nature and consist of a collection of substitution rules referred to as productions. Their recursive nature empowers them to be widely expressive as you will see in many real-world examples throughout the specification. To apply the grammar, you start with the top rule, and simply perform substitutions until there are no non-terminals on the right-hand side. The top-left non-terminal is known as the goal terminal because our goal is to define it with everything on its right. In our example, valid syntax that will conform to our grammar include 0@1 00@11 000@111 and so on.

Why the name ‘context-free’?

What makes something ‘context-free’ and why is it called that? Consider the following:

In the first rule you can replace A without worrying about anything else around it, i.e. context-free. However, with the second rule, you can only replace A if B is alongside it. This means that you need to worry about the context of A being next to B. That is why AB : a isn’t context-free! For a formula to be context-free it must have only one non-terminal on the left-hand side. More than one non-terminal and we no longer have a context-free formula.

Armed with all this information we can understand 5.1.1 of the spec.

A context-free grammar consists of a number of productions. Each production has an abstract symbol called a nonterminal as its left-hand side, and a sequence of zero or more nonterminal and terminal symbols as its right-hand side. For each grammar, the terminal symbols are drawn from a specified alphabet.

There we go! Exactly like we described albeit less cryptic now that we know what it’s talking about.

A chain production is a production that has exactly one nonterminal symbol on its right-hand side along with zero or more terminal symbols.

It’s called a chain because the rules or productions are linked together like a chain. A chain provides an optimal level of simplicity.

Starting from a sentence consisting of a single distinguished nonterminal, called the goal symbol, a given context-free grammar specifies a language, namely, the (perhaps infinite) set of possible sequences of terminal symbols that can result from repeatedly replacing any nonterminal in the sequence with a right-hand side of a production for which the nonterminal is the left-hand side.

Run-on sentence anyone? It’s not technically a run-on, but it is definitely a mouthful. If you read it chunk by chunk you’ll see that it re-iterates what we already know from what we just discussed.

Web Scripting

ES6 Language Specification

4.1 Web Scripting

An overview of the role ECMAScript can play in the web client and web server. Using ES for both provides for an even more powerful computational environment in which tasks can be fluidly distributed between the client and server.

A web browser provides an ECMAScript host environment for client-side computation including, for instance, objects that represent windows, menus, pop-ups, dialog boxes, text areas, anchors, frames, history, cookies, and input/output. Further, the host environment provides a means to attach scripting code to events such as change of focus, page and image loading, unloading, error and abort, selection, form submission, and mouse actions. Scripting code appears within the HTML and the displayed page is a combination of user interface elements and fixed and computed text and images. The scripting code is reactive to user interaction and there is no need for a main program.

A web server provides a different host environment for server-side computation including objects representing requests, clients, and files; and mechanisms to lock and share data. By using browser-side and server-side scripting together, it is possible to distribute computation between the client and server while providing a customized user interface for a Web-based application.

Each Web browser and server that supports ECMAScript supplies its own host environment, completing the ECMAScript execution environment.


ES6 Language Specification

4. Overview

This section contains a non-normative overview of the ECMAScript language.

In other words it is an informal overview. Don’t confuse that to mean less important. It’s just not formal or binding in the same way as the normative parts of the spec. However, this is an interesting, and highly-informative section of the specification.

ECMAScript is an object-oriented programming language for performing computations and manipulating computational objects within a host environment. 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 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.

In other words, ECMAScript is a programming language that requires additional features provided by its hosting environment. Most commonly this is the web browser, but it can be a web server or another operating environment that implements the language.

ECMAScript was originally designed to be used as a scripting language, but has become widely used as a general purpose programming language. A scripting language is a programming language that is used to manipulate, customize, and automate the facilities of an existing system. In such systems, useful functionality is already available through a user interface, and the scripting language is a mechanism for exposing that functionality to program control. In this way, the existing system is said to provide a host environment of objects and facilities, which completes the capabilities of the scripting language. A scripting language is intended for use by both professional and non-professional programmers.

ECMAScript was originally designed to be a Web scripting language, providing a mechanism to enliven Web pages in browsers and to perform server computation as part of a Web-based client-server architecture. ECMAScript is now used to provide core scripting capabilities for a variety of host environments. Therefore the core language is specified in this document apart from any particular host environment.

ECMAScript usage has moved beyond simple scripting and it is now used for the full spectrum of programming tasks in many different environments and scales. As the usage of ECMAScript has expanded, so has the features and facilities it provides. ECMAScript is now a fully featured general propose programming language.

Some of the facilities of ECMAScript are similar to those used in other programming languages; in particular C, Java™, Self, and Scheme as described in:

ISO/IEC 9899:1996, Programming Languages – C.

Gosling, James, Bill Joy and Guy Steele. The Java Language Specification. Addison Wesley Publishing Co., 1996.

Ungar, David, and Smith, Randall B. Self: The Power of Simplicity. OOPSLA ’87 Conference Proceedings, pp. 227–241, Orlando, FL, October 1987.

IEEE Standard for the Scheme Programming Language. IEEE Std 1178-1990.

ECMAScript originated by Netscape for use as a scripting language in browsers. It was created to enhance webpages and accessible to non-professional programmers. However, as we know, the language has evolved, grown, and blossomed into a fully featured and powerful general purpose programming language to be used in a host of environments.

Normative references

ES6 Language Specification

3. Normative references

Listed are 3 external specifications that go hand-in-hand with ECMAScript:

The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

ISO/IEC 10646:2003: Information Technology – Universal Multiple-Octet Coded Character Set (UCS) plus Amendment 1:2005, Amendment 2:2006, Amendment 3:2008, and Amendment 4:2008, plus additional amendments and corrigenda, or successor

ECMA-402, ECMAScript 2015 Internationalization API Specification.

ECMA-404, The JSON Data Interchange Format.

  1. ISO/IEC 10646. This is a low level spec that is incorporated as part of Unicode. As mentioned in its abstract, this specification focuses on the “representation, transmission, interchange, processing, storage, input and presentation of the written form of the languages of the world as well as additional symbols”.
  2. ECMA-402. As mentioned earlier, this is the standard that needs to be referenced by implementations that provide international APIs. Known also as ECMAScript 2015 Internationalization API Specification.
  3. ECMA-404. This is the JSON specification. It is only 5 pages long. Although originally derived from ECMAScript, it is not part of the ECMAScript spec, because it is intended to be language independent.


ES6 Language Specification

2. Conformance

Popular implementations of ECMAScript include Chrome’s V8 Engine, Firefox’s SpiderMonkey,  and Microsoft Edge’s Chakra. To properly conform to ECMAScript the following criteria must be met:

A conforming implementation of ECMAScript must provide and support all the types, values, objects, properties, functions, and program syntax and semantics described in this specification.

A conforming implementation of ECMAScript must interpret source text input in conformance with the Unicode Standard, Version 5.1.0 or later and ISO/IEC 10646. If the adopted ISO/IEC 10646-1 subset is not otherwise specified, it is presumed to be the Unicode set, collection 10646.

A conforming implementation of ECMAScript that provides an application programming interface that supports programs that need to adapt to the linguistic and cultural conventions used by different human languages and countries must implement the interface defined by the most recent edition of ECMA-402 that is compatible with this specification.

A conforming implementation of ECMAScript may provide additional types, values, objects, properties, and functions beyond those described in this specification. In particular, a conforming implementation of ECMAScript may provide properties not described in this specification, and values for those properties, for objects that are described in this specification.

A conforming implementation of ECMAScript may support program and regular expression syntax not described in this specification. In particular, a conforming implementation of ECMAScript may support program syntax that makes use of the “future reserved words” listed in subclause of this specification.

A conforming implementation of ECMAScript must not implement any extension that is listed as a Forbidden Extension in subclause 16.1.

In other words the following must be true to be considered a valid implementation of ECMAScript:

  1. Must support all the language features, syntax, and semantics provided in this spec.
  2. Must interpret source code in Unicode, minimum version 5.1, although note that Unicode 8.0 is available as of 2015. Implied and incorporated in every Unicode standard is ISO/IEC 10646.
  3. If the implementation provides APIs to support internationalization, then those must conform to the interface specified by the ECMAScript 2015 Internationalization API Specification, referred to here as ECMA-402.
  4. May create additional features beyond the core ECMAScript functionality.
  5. May provide additional syntax beyond what’s in the spec. This includes using future reserved words (enum, await, implements, interface, package, private, protected, and public).
  6. Cannot implement forbidden extensions which will be the topic of a future post.


ES6 Language Specification

1. Scope

This Standard defines the ECMAScript 2015 general purpose programming language.

Simple enough. Perhaps the most straightforward part of the spec!


ES6 Language Specification


This Ecma Standard defines the ECMAScript 2015 Language. It is the sixth edition of the ECMAScript Language Specification. Since publication of the first edition in 1997, ECMAScript has grown to be one of the world’s most widely used general purpose programming languages. It is best known as the language embedded in web browsers but has also been widely adopted for server and embedded applications. The sixth edition is the most extensive update to ECMAScript since the publication of the first edition in 1997.

ECMAScript, widely known by Oracle’s trademarked name Javascript, has been around for over 2 decades. Javascript was initially developed in May 1995 by Brandon Eich. However, the first version of the ECMAScript standard for the language was released in 1997, and the last major update to the standard prior to 2015 was back in 2009. ECMAScript has been painstakingly built by many renowned experts in the programming world, and incorporates an extremely extensive and impressive array of features into the language. ECMAScript 2015 (which we frequently refer to as ES6 for brevity) ushers in a realm of amazing new possibilities and one that is increasingly better positioned as a tool not just for the web, but for applications everywhere.


Goals for ECMAScript 2015 include providing better support for large applications, library creation, and for use of ECMAScript as a compilation target for other languages. Some of its major enhancements include modules, class declarations, lexical block scoping, iterators and generators, promises for asynchronous programming, destructuring patterns, and proper tail calls. The ECMAScript library of built-ins has been expanded to support additional data abstractions including maps, sets, and arrays of binary numeric values as well as additional support for Unicode supplemental characters in strings and regular expressions. The built-ins are now extensible via subclassing.

The previous paragraph provides a high-level overview of new features added to the language. Each of the items listed are significant additions to the language and often garner a chapter dedicated to each of them in programming books and literature.

The story of ECMAScript

ECMAScript is based on several originating technologies, the most well-known being JavaScript (Netscape) and JScript (Microsoft). The language was invented by Brendan Eich at Netscape and first appeared in that company’s Navigator 2.0 browser. It has appeared in all subsequent browsers from Netscape and in all browsers from Microsoft starting with Internet Explorer 3.0.

Brendan Eich was commissioned by Netscape in 1995 to create a programming language to be used in the pioneering Netscape Navigator web browser. While being developed the name for the language was Mocha, but upon its initial release was renamed LiveScript. In September in 1995, Netscape renamed LiveScript to JavaScript upon the beta release of its Netscape Navigator 2.0 web browser. The name JavaScript is trademarked, so in 1996 Microsoft released a language called JScript, which is a reverse-engineered version of Javascript, for use in Internet Explorer 3. The browser wars that followed, and the difficultly developers were having in making their applications work well cross-platform, prompted Netscape to submit JavaScript to the Ecma International organization for official standardization. The resulting standardization of JavaScript and the nearly identical JScript was released in 1997 under the official name ECMAScript.


The development of the ECMAScript Language Specification started in November 1996. The first edition of this Ecma Standard was adopted by the Ecma General Assembly of June 1997.


That Ecma Standard was submitted to ISO/IEC JTC 1 for adoption under the fast-track procedure, and approved as international standard ISO/IEC 16262, in April 1998. The Ecma General Assembly of June 1998 approved the second edition of ECMA-262 to keep it fully aligned with ISO/IEC 16262. Changes between the first and the second edition are editorial in nature.

In other words, not much changed between the first and second edition other than some editorial changes.


The third edition adopted in 1999 and published in 2002 introduced important and basic features to the language such as try/catch handling, and regular expressions. ES3 was widely adopted and is fully supported by browsers as far back as Internet Explorer 6.

The third edition of the Standard introduced powerful regular expressions, better string handling, new control statements, try/catch exception handling, tighter definition of errors, formatting for numeric output and minor changes in anticipation future language growth. The third edition of the ECMAScript standard was adopted by the Ecma General Assembly of December 1999 and published as ISO/IEC 16262:2002 in June 2002.


Unfortunately, disagreements as to the future of the language arose post-release of the third edition.

After publication of the third edition, ECMAScript achieved massive adoption in conjunction with the World Wide Web where it has become the programming language that is supported by essentially all web browsers. Significant work was done to develop a fourth edition of ECMAScript. However, that work was not completed and not published as the fourth edition of ECMAScript but some of it was incorporated into the development of the sixth edition.

The reason for this is that many in the committee believed ES4 was too ambitious, and perhaps it was, as in 2008 the spec was dropped and an agreement called ECMAScript Harmony was formed. The executive summary of the 2008 agreement states:

Subsequently, ES3.1 was released in 2009 as ES5 and slightly revised in 2011 as ES5.1, while much of the original ES4 was incorporated into the sweeping changes of ES6.


Very important yet modest features made their way into ES5. Important new features include enhanced object creation and control properties/functions, utility array functions, strict mode, and native JSON support. ES5 has full native support in IE9+, Firefox 4+, and Chrome 7+.

The fifth edition of ECMAScript (published as ECMA-262 5th edition) codified de facto interpretations of the language specification that have become common among browser implementations and added support for new features that had emerged since the publication of the third edition. Such features include accessor properties, reflective creation and inspection of objects, program control of property attributes, additional array manipulation functions, support for the JSON object encoding format, and a strict mode that provides enhanced error checking and program security. The Fifth Edition was adopted by the Ecma General Assembly of December 2009.

The fifth Edition was submitted to ISO/IEC JTC 1 for adoption under the fast-track procedure, and approved as international standard ISO/IEC 16262:2011. Edition 5.1 of the ECMAScript Standard incorporated minor corrections and is the same text as ISO/IEC 16262:2011. The 5.1 Edition was adopted by the Ecma General Assembly of June 2011.


Focused development of the sixth edition started in 2009, as the fifth edition was being prepared for publication. However, this was preceded by significant experimentation and language enhancement design efforts dating to the publication of the third edition in 1999. In a very real sense, the completion of the sixth edition is the culmination of a fifteen year effort.

Dozens of individuals representing many organizations have made very significant contributions within Ecma TC39 to the development of this edition and to the prior editions. In addition, a vibrant informal community has emerged supporting TC39’s ECMAScript efforts. This community has reviewed numerous drafts, filed thousands of bug reports, performed implementation experiments, contributed test suites, and educated the world-wide developer community about ECMAScript. Unfortunately, it is impossible to identify and acknowledge every person and organization who has contributed to this effort.

Indeed! ES6 is among the most exciting developments in modern programming history. It is a sweeping set of additions to one of the world’s most popular languages. It indeed reflects 15 years of collaboration and effort by many of the brightest minds in our industry.


New uses and requirements for ECMAScript continue to emerge. The sixth edition provides the foundation for regular, incremental language and library enhancements.

Moving forward, the goal is to produce yearly, incremental, updates to the language. ES6 or ECMAScript 2015 is the start of this exciting process!