ECMAScript 4 Netscape Proposal Introduction Motivation

Wednesday, September 4, 2002

Goals

The main goals of ECMAScript 4 are:

• Making the language suitable for writing modular and object-oriented applications
• Making it possible and easy to write robust and secure applications
• Improving upon ECMAScript’s facilities for interfacing with a variety of other languages and environments
• Improving ECMAScript’s suitability for writing applications for which performance matters
• Simplifying the language where possible
• Keeping the language implementation compact and flexible

The following are specifically not goals of ECMAScript 4:

• Making ECMAScript 4 suitable for all programming tasks
• Making ECMAScript 4 similar to any existing programming language

ECMAScript is not currently an all-purpose programming language. Its strengths are its quick execution from source (thus enabling it to be distributed in web pages in source form), its dynamism, and its interfaces to Java and other environments. ECMAScript 4 is intended to improve upon these strengths, while adding others such as the abilities to reliably compose ECMAScript programs out of components and libraries and to write object-oriented programs. On the other hand, it is not our intent to have ECMAScript 4 supplant languages such as C++ and Java, which will still be more suitable for writing many kinds of applications, including very large, performance-critical, and low-level ones.

Rationale

The proposed features are derived from the goals above. Consider, for example, the goals of writing modular and robust applications.

To achieve modularity we would like some kind of a library mechanism. The proposed package mechanism serves this purpose, but by itself it would not be enough. Unlike existing ECMAScript programs which tend to be monolithic, packages and their clients are often written by different people at different times. Once we introduce packages, we encounter the problems of the author of a package not having access to all of its clients, or the author of a client not having access to all versions of the library it needs. If we add packages to the language without solving these problems, we will never be able to achieve robustness, so we must address these problems by creating facilities for defining abstractions between packages and clients.

To create these abstractions we make the language more disciplined by adding optional types and type-checking. We also introduce a coherent and disciplined syntax for defining classes and hierarchies and versioning of classes. Unlike ECMAScript 3, the author of a class can guarantee invariants concerning its instances and can control access to its instances, making the package author’s job tractable. The class syntax is also much more self-documenting than in ECMAScript 3, making it easier to understand and use ECMAScript 4 code. Defining subclasses is easy in ECMAScript 4, while doing it robustly in ECMAScript 3 is quite difficult.

To make packages work we need to make the language more robust in other areas as well. It would not be good if one package redefined Object.toString or added methods to the Array prototype and thereby corrupted another package. We can simplify the language by eliminating many idioms like these (except when running legacy programs, which would not use packages) and provide better alternatives instead. This has the added advantage of speeding up the language’s implementation by eliminating thread synchronization points. Making the standard packages robust can also significantly reduce the memory requirements and improve speed on servers by allowing packages to be shared among many different requests rather than having to start with a clean set of packages for each request because some other request might have modified some property.

ECMAScript 4 should interface with other languages even better than ECMAScript 3 does. If the goal of integration is achieved, the user of an abstraction should not have to care much about whether the abstraction is written in ECMAScript, Java, or another language. It should also be possible to make ECMAScript abstractions that appear native to Java or other language users.

In order to achieve seamless interfacing with other languages, ECMAScript should provide equivalents for the fundamental data types of those languages. Details such as syntax do not have to be the same, but the concepts should be there. ECMAScript 3 lacks support for integers, making it hard to interface with a Java method that expects a long.

ECMAScript is appearing in a number of different application domains, many of which are evolving. Rather than support all of these domains in the core ECMAScript, ECMAScript 4 should provide flexible facilities that allow these application domains to define their own, evolving standards that are convenient to use without requiring continuous changes to the core of ECMAScript. ECMAScript 4 partially addresses this goal by letting user programs define facilities such as getters and setters — facilities that could only be done by the core of the language in ECMAScript 3.

Waldemar Horwat Last modified Wednesday, September 4, 2002