JavaScript 2.0:
`Evolving a Language for Evolving Systems
`
`Waldemar Horwat
`waldemar@acm.org
`
`Abstract
`JavaScript 2.0 is the next major revision of the JavaScript language. Also known as ECMAScript
`Edition 4, it is being standardized by the ECMA organization. This paper summarizes the needs
`that drove the revision in the language and then describes some of the major new features of the
`language to meet those needs — support for API evolution, classes, packages, object protection,
`dynamic types, and scoping. JavaScript is a very widely used language, and evolving it presented
`many unique challenges as well as some opportunities. The emphasis is on the rationale, insights,
`and constraints that led to the features rather than trying to describe the complete language.
`
`1 Introduction
`
`1.1 Background
`JavaScript [6][8] is a web scripting language
`invented by Brendan Eich at Netscape. This
`language first appeared
`in 1996 as
`JavaScript 1.0 in Navigator 2.0. Since then
`the language has undergone numerous addi-
`tions and revisions [6], and the most recent
`released version is JavaScript 1.5.
`
`JavaScript has been enormously successful
`— it is more than an order of magnitude
`more widely used than all other web client
`languages combined. More than 25% of web
`pages use JavaScript.
`
`JavaScript programs are distributed in
`source form, often embedded inside web
`page elements, thus making it easy to author
`them without any tools other than a text
`editor. This also makes it easier to learn the
`language by examining existing web pages.
`
`There is a plethora of synonymous names
`for JavaScript. JavaScript, JScript, and
`ECMAScript are all the same language.
`JavaScript was originally called LiveScript
`but was renamed to JavaScript just before it
`was released. JavaScript is not related to
`Java, although the two language implemen-
`tations can communicate with each other in
`
`Netscape browsers through an interface
`called LiveConnect.
`
`JavaScript as a language has computational
`facilities only — there are no input/output
`primitives defined within the language. In-
`stead, each embedding of JavaScript within
`a particular environment provides the means
`to interact with that environment. Within a
`web browser JavaScript is used in conjunc-
`tion with a set of common interfaces, in-
`cluding the Document Object Model [11],
`which allow JavaScript programs to interact
`with web pages and the user. These inter-
`faces are described by separate standards
`and are not part of the JavaScript language
`itself. This paper concentrates on the
`JavaScript language rather than the inter-
`faces.
`
`1.2 Standardization
`After Netscape released JavaScript in Navi-
`gator 2.0, Microsoft implemented the lan-
`guage, calling it JScript, in Internet Ex-
`plorer 3.0. Netscape, Microsoft, and a num-
`ber of other companies got together and
`formed the TC39 committee in the ECMA
`standards organization [2] in order to agree
`on a common definition of the language.
`The first ECMA standard [3], calling the
`language ECMAScript, was adopted by the
`ECMA general assembly in June 1997 as the
`ECMA-262 standard. The second edition of
`
`JavaScript 2.0: Evolving a Language for Evolving Systems
`
`1
`
` Exhibit 1027 Page 1
`
` SYMANTEC
`
`

`
`attributes and conditional compilation (Sec-
`tion 8). Section 9 concludes.
`
`2 JavaScript 1.5
`JavaScript 1.5 (ECMAScript Edition 3) is an
`object-based scripting language with a syn-
`tax similar to C and Java. Statements such as
`i f , w h i l e , f o r , s w i t c h , and
`throw/try/c a t c h will be familiar to
`C/C++ or Java programmers. Functions,
`declared using the function keyword, can
`nest and form true closures. For example,
`given the definitions
`function square(x) {
` return x*x;
`
`} f
`
`unction add(a) {
` return function(b) {
` return a+b;
` }
`}
`evaluating the expressions below produces
`the values listed after the fi symbols:
`square(5) fi 25
`var f = add(3);
`var g = add(6);
`f(1) fi 4;
`g(5) fi 11;
`
`A function without a return statement
`returns the value undefined.
`
`Like Lisp, JavaScript provides an e v a l
`function that takes a string and compiles and
`evaluates it as a JavaScript program; this
`allows self-constructing and self-modifying
`code. For example:
`eval("square(8)+3") fi 67
`eval("square = f") fi The
`source code for function f
`square(2) fi 5
`
`2.1 Values and Variables
`The basic values of JavaScript 1.5 are num-
`bers (double-precision IEEE floating-point
`values including +0.0, –0.0, +∞, –∞, and
`NaN), booleans (t r u e and false), the
`
`this standard, ECMA-262 Edition 2 [4], con-
`sisted mainly of editorial fixes gathered in
`the process of making the ECMAScript ISO
`standard 16262. The third edition of the
`ECMAScript standard [5] was adopted in
`December 1999 and added numerous new
`features, including regular expressions,
`nested functions and closures, array and ob-
`ject literals, the switch and do-while
`statements, and exceptions. JavaScript 1.5
`fully implements ECMAScript Edition 3.
`
`I’ve been involved at Netscape with both the
`implementation and standardization of
`JavaScript since 1998. I wrote parts of the
`ECMAScript Edition 3 standard and am cur-
`rently the editor of the draft ECMAScript
`Edition 4 standard.
`
`In Editions 1 and 2, the ECMA committee
`standardized existing practice, as the lan-
`guage had already been implemented by
`Netscape, and Microsoft closely mirrored
`that implementation. In Edition 3, the role of
`the committee shifted to become more active
`in the definition of new language features
`before they were implemented by the ven-
`dors; without this approach, the vendors’
`implementations would have quickly di-
`verged. This role continues with Edition 4,
`and, as a result, the interesting language de-
`sign discussions take place mainly within
`the ECMA TC39 (now TC39TG1) working
`group.
`
`This paper presents the results of a few of
`these discussions. Although many of the is-
`sues have been settled, Edition 4 has not yet
`been approved or even specified in every
`detail. It is still likely to change and should
`definitely be considered a preliminary draft.
`
`1.3 Outline
`Section 2 gives a brief description of the
`existing language JavaScript 1.5. Section 3
`summarizes the motivation behind Java-
`Script 2.0. Individual areas and decisions are
`covered in subsequent sections: types (Sec-
`tion 4); scoping and syntax issues (Sec-
`tion 5); classes (Section 6); namespaces,
`versioning, and packages (Section 7); and
`
`JavaScript 2.0: Evolving a Language for Evolving Systems
`
`2
`
` Exhibit 1027 Page 2
`
` SYMANTEC
`
`

`
`strange("Apple ", false) fi
`"Apple Hello"
`strange(20, true) fi
`"40Hello"
`The last example also shows that + is poly-
`morphic — it adds numbers, concatenates
`strings, and, when given a string and a num-
`ber, converts the number to a string and
`concatenates it with the other string.
`
`2.2 Objects
`JavaScript 1.5 does not have classes; in-
`stead, general objects use a prototype
`mechanism to mimic inheritance. Every ob-
`ject is a collection of name-value pairs
`called properties, as well as a few special,
`hidden properties. One of the hidden prop-
`erties is a prototype link1 which points to
`another object or null.
`
`When reading property p of object x using
`the expression x.p, the object x is searched
`first for a property named p. If there is one,
`its value is returned; if not, x’s prototype
`(let’s call it y) is searched for a property
`named p. If there isn’t one, y’s prototype is
`searched next and so on. If no property at all
`is
`found,
`the
`result
`is
`the value
`undefined.
`
`When writing property p of object x using
`the expression x.p = v, a property named p
`is created in x if it’s not there already and
`then assigned the value v. x’s prototype is
`not affected by the assignment. The new
`property p in x will then shadow any prop-
`erty with the same name in x’s prototype and
`can only be removed using the expression
`delete x.p.
`
`A property can be read or written using an
`indirect name with the syntax x[s], where s
`is an expression that evaluates to a string (or
`a value that can be converted into a string)
`representing a property name. If s contains
`the string "blue", then the expression
`x[s] is equivalent to x.blue. An array is
`
`1 For historical reasons in Netscape’s JavaScript this hidden
`prototype link is accessible as the property named
`__proto__, but this is not part of the ECMA standard.
`
`special values null and undefined, im-
`mutable Unicode strings, and general ob-
`jects, which include arrays, regular expres-
`sions, dates, functions, and user-defined ob-
`jects. All values have unlimited lifetime and
`are deleted only via garbage collection,
`which is transparent to the programmer.
`
`Variables are not statically typed and can
`hold any value. Variables are introduced
`using var declarations as in:
`var x;
`var y = z+5;
`
`An uninitialized variable gets the value
`undefined. Variable declarations are
`lexically scoped, but only at function
`boundaries — all declarations directly
`within a function apply to the entire func-
`tion, even above the point of declaration.
`Local blocks do not form scopes. If a func-
`tion accesses an undeclared variable, it is
`assumed to be a global variable. For exam-
`ple, in the definitions
`function init(a) {
` b = a;
`
`} f
`
`unction strange(s, t) {
` a = s;
` if (t) {
` var a;
` a = a+a;
` }
` return a+b;
`}
`function strange defines a local variable
`a. It doesn’t matter that the var statement is
`nested within the if statement — the var
`statement creates a at the beginning of the
`function regardless of the value of t.
`
`At this point evaluating
`strange("Apple ", false)
`signals an error because the global variable
`b is not defined. However, the following
`statements evaluate successfully because
`init creates the global variable b:
`init("Hello") fi undefined
`
`JavaScript 2.0: Evolving a Language for Evolving Systems
`
`3
`
` Exhibit 1027 Page 3
`
` SYMANTEC
`
`

`
`method can refer to the object on which it
`was invoked using the this variable:
`
`function Radius() {
` return Math.sqrt(
` this.x*this.x +
` this.y*this.y);
`}
`
`The following statement attaches Radius
`as a property named radius visible from
`any Point object via its prototype:
`
`Point.prototype.radius =
`Radius;
`
`a.radius() fi 5
`
`The situation becomes much more compli-
`cated when trying to define a prototype-
`based hierarchy more than one level deep.
`There are many subtle issues [9], and it is
`easy to define one with either too much or
`too little sharing.
`
`2.3 Permissiveness
`JavaScript 1.5 is very permissive — strings,
`numbers, and other values are freely coerced
`into one another; functions can be called
`with the wrong number of arguments; global
`variable declarations can be omitted; and
`semicolons separating statements on differ-
`ent lines may be omitted in unambiguous
`situations. This permissiveness is a mixed
`blessing — in some situations it makes it
`easier to write programs, but in others it
`makes it easier to suffer from hidden and
`confusing errors.
`
`For example, nothing in JavaScript distin-
`guishes among regular functions (square
`in the examples above), functions intended
`as constructors (Point), and functions in-
`tended as methods (Radius). JavaScript
`lets one call Point defined above as a
`function (without new and without attaching
`it to an object),
`p = Point(3)
`which creates global variables x and y if
`they didn’t already exist (or overwrites them
`if they did) and then writes 3 to x and
`
`an object with properties named "0", "1",
`"2", …, "576", etc.; not all of these need
`be present, so arrays are naturally sparse.
`
`An object is created by using the new op-
`erator on any function call: new f(args).
`An object with no properties is created be-
`fore entering the function and is accessible
`from inside the function via the this vari-
`able.
`
`The function f itself is an object with several
`properties. In particular, f.prototype
`points to the prototype that will be used for
`objects created via new f(args).2 An ex-
`ample illustrates these concepts:
`function Point(px, py) {
` this.x = px;
` this.y = py;
`
`} a
`
` = new Point(3,4);
`origin = new Point(0,0);
`
`a.x fi 3
`a["y"] fi 4
`
`The prototype can be altered dynamically:
`Point.prototype.color =
`"red";
`
`a.color fi "red"
`origin.color fi "red"
`
`The object a can shadow its prototype as
`well as acquire extra properties:
`a.color = "blue";
`a.weight = "heavy";
`
`a.color fi "blue"
`a.weight fi "heavy"
`origin.color fi "red"
`origin.weight fi undefined
`
`Methods can be attached to objects or their
`prototypes. A method is any function. The
`
`
`2 Using the notation from the previous footnote, after
`o = new f(args),
`o.__proto__ == f.prototype.
`f.prototype is not to be confused with function f’s own
`prototype f.__proto__, which points to the global proto-
`type of functions Function.prototype.
`
`JavaScript 2.0: Evolving a Language for Evolving Systems
`
`4
`
` Exhibit 1027 Page 4
`
` SYMANTEC
`
`

`
`undefined to y. The variable p gets the
`value undefined. Obvious, right? (If this
`is obvious, then you’ve been spending far
`too much time reading language standards.)3
`
`2.4 Exploring Further
`This is only a brief overview of JavaScript
`1.5. See a good reference [6] for the details.
`To get an interactive JavaScript shell, type
`javascript: as the URL in a Netscape
`browser or download and compile the source
`code for a simple stand-alone JavaScript
`shell from [8].
`
`3 JavaScript 2.0 Motivation
`JavaScript 2.0 is Netscape’s implementation
`of the ECMAScript Edition 4 standard cur-
`rently under development. The proposed
`standard is motivated by the need to achieve
`better support for programming in the large
`as well as fix some of the existing problems
`in JavaScript (section 5).
`
`3.1 Programming in the Large
`As used here, programming in the large does
`not mean writing large programs. Rather, it
`refers to:
`• Programs written by more than one per-
`son
`• Programs assembled from components
`(packages)
`• Programs that live in heterogeneous en-
`vironments
`• Programs that use or expose evolving
`interfaces
`• Long-lived programs that evolve over
`time
`Many applications on the web fall into one
`or more of these categories.
`
`
`3 The reason that global variables x and y got created is that
`when one doesn’t specify a this value when calling a func-
`tion such as Point, then this refers to the global scope
`object; thus this.x = px creates the global variable x.
`
`3.2 Mechanisms
`A package facility (separable libraries that
`export top-level definitions — see section 7)
`helps with some of the above requirements
`but, by itself, is not sufficient. Unlike exist-
`ing JavaScript programs which tend to be
`monolithic, packages and their clients are
`typically written by different people at dif-
`ferent times. This presents the problem of
`the author or maintainer of a package not
`having access to all of its clients to test the
`package, or, conversely, the author of a cli-
`ent not having access to all versions of the
`package to test against — even if the author
`of a client could test his client against all ex-
`isting versions of a package, he is not able to
`test against future versions. Merely adding
`packages to a language without solving
`these problems would not achieve robust-
`ness; instead, additional facilities for defin-
`ing stronger boundaries between packages
`and clients are needed.
`
`One approach that helps is to make the lan-
`guage more disciplined by adding optional
`types and type-checking (section 4). Another
`is a coherent and disciplined syntax for de-
`fining classes (section 6) together with a ro-
`bust means for versioning of classes. Unlike
`JavaScript 1.5, 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.
`Versioning (section 7) and enforceable in-
`variants simplify the package author’s job of
`evolving an already-published package, per-
`haps expanding its exposed interface, with-
`out breaking existing clients. Conditional
`compilation (section 8) allows the author of
`a client to craft a program that works in a
`variety of environments, taking advantage of
`optional packages if they are provided and
`using workarounds if not.
`
`To work in multi-language environments,
`JavaScript 2.0 provides better mappings for
`data types and interfaces commonly exposed
`by other languages. It includes support for
`classes as well as previously missing basic
`types such as long.
`
`JavaScript 2.0: Evolving a Language for Evolving Systems
`
`5
`
` Exhibit 1027 Page 5
`
` SYMANTEC
`
`

`
`var v:type = value;
`where v is the name of the variable and type
`is a constant expression that evaluates to a
`type. Types can also be attached to function
`parameters and results.
`
`A variable declared with a type is guaran-
`teed to always hold an element of that type5.
`Assigning a value to that variable coerces
`the value to the type or generates an error if
`the coercion is not allowed. To catch errors,
`such coercions are less permissive than
`JavaScript 1.5’s coercions.
`
`4.2 Strong Dynamic Typing
`JavaScript 2.0 is strongly typed — type
`declarations are enforced. On the other hand,
`JavaScript 2.0 is not statically typed — the
`compiler does not verify that type errors
`cannot occur at run time. To illustrate the
`difference, consider the class definitions
`below, which define a class A with instance
`variable x and a subclass B of A with an ad-
`ditional instance variable y:
`class A {
` var x;
`
`} c
`
`lass B extends A {
` var y;
`}
`
`Given the above, the following statements
`all work as expected:
`var a:A = new A;
`var b:B = new B;
`a = b;
`var o = new A;
`
`An untyped variable such as o is considered
`to have type Object, so it admits every
`value. The following statements, which
`would be errors in a statically typed lan-
`guage, also execute properly because the
`run-time values being assigned are of the
`proper type:
`
`
`5 Actually, the rule is that successfully reading a variable
`always returns an element of the variable’s type. This is
`because a variable may be in an uninitialized state, in which
`case trying to read it generates an error.
`
`3.3 Non-Goals
`JavaScript 2.0 is intended for a specific
`niche of scripting languages. It is meant to
`be a glue language. It is not meant to be:
`• a high-performance language
`• a language for writing general-purpose
`applications such as spreadsheets, word
`processors, etc.
`• a language for writing huge programs
`• a stripped-down version of an existing
`language
`
`Although many of the facilities provided
`improve performance, that by itself is not
`their reason for inclusion in the language.
`
`4 Type System
`JavaScript 2.0 supports the notion of a type,
`which can be thought of as a subset of all
`possible values. There are some built-in
`types such as O b j e c t , Number, and
`String; each user-defined class (section 6)
`is also a type.
`
`The root of the type hierarchy is Object.
`Every value is a member of the type
`Object. Unlike in JavaScript 1.5, there is
`no real distinction between primitive values
`and objects4.
`
`Unlike in C and Java, types are first-class
`values. Type expressions are merely value
`expressions that evaluate to values that are
`types; therefore, type expressions use the
`same syntax as value expressions.
`
`4.1 Type Declarations
`Variables in JavaScript 2.0 can be typed us-
`ing the syntax
`
`
`4 The bizarre JavaScript 1.5 dichotomy between
`String,
`Number, and Boolean values and String, Number, and
`Boolean objects is eliminated, although an implementation
`may preserve it as an optional language extension for com-
`patibility. All JavaScript 2.0 values behave as though they are
`objects — they have methods and properties — although
`some of the more important classes such as String,
`Number, etc. are final and don’t allow the creation of
`dynamic properties, so their instances can be transparently
`implemented as primitives.
`
`JavaScript 2.0: Evolving a Language for Evolving Systems
`
`6
`
` Exhibit 1027 Page 6
`
` SYMANTEC
`
`

`
`b = a;
`a = o;
`
`On the other hand, assigning b = o gen-
`erates a run-time error because o does not
`currently contain an instance of B.
`
`Because JavaScript is not statically typed,
`function sum below also compiles correctly;
`it would be a compile-time error in a stati-
`cally typed language because the compiler
`could not statically prove that c will have a
`property named y.6
`function sum(c:A) {
` return c.x + c.y;
`}
`
`The assignment to z1 will execute success-
`fully, while the assignment to z2 will gen-
`erates a run-time error when trying to look
`up c.y:7
`var z1 = sum(new B);
`var z2 = sum(new A);
`
`The declaration c:A inside sum is still en-
`forced — it requires that the argument
`passed to sum must be a member of type A;
`thus, an attempt to call sum on an instance
`of some class C unrelated to A would gener-
`ate an error even if that instance happened to
`have properties x and y.
`
`The general principle here is that only the
`actual run-time type of an expression’s value
`matters — unlike statically typed languages
`such as C++ and Java, JavaScript 2.0 has no
`concept of the static type of an expression.
`
`
`6 If class A were final, a smart JavaScript compiler could
`issue a compile-time error for function sum because it could
`prove that no possible value of c could have a property
`named y. The difference here is that a compiler for a stati-
`cally typed language will issue an error if it cannot prove that
`the program will work without type errors. A compiler for a
`dynamically typed language will issue an error only if it can
`prove that the program cannot work without type errors;
`strong typing is ensured at run time.
`7 Unlike with prototype-based objects, by default an attempt
`to refer to a nonexistent property of a class instance signals
`an error instead of returning undefined or creating the
`property. See section 6.
`
`4.3 Rationale
`Why doesn’t JavaScript 2.0 support static
`typing? Although this would help catch pro-
`grammer errors, it would also dramatically
`change the flavor of the language. Many of
`the familiar idioms would no longer work,
`and the language would need to acquire the
`concept of interfaces which would then have
`to be used almost everywhere. Followed to
`the logical conclusion, the language would
`become nearly indistinguishable from Java
`or C#; there is no need for another such lan-
`guage.
`
`is why
`Another common question
`JavaScript 2.0 uses the colon notation for
`type annotation instead of copying the C-
`like syntax. Embarrassingly, this is a deci-
`sion based purely on a historical standards
`committee vote — this seemed like a good
`idea at one time. There is no technical rea-
`son for using this syntax, but it’s too late to
`reverse it now (implementations using this
`syntax have already shipped), even though
`most of the people involved with it admit the
`syntax is a mistake.
`
`5 Scoping and Strict Mode
`JavaScript 1.5 suffers from a number of de-
`sign mistakes (see sections 2.1 and 2.3 for
`some examples) that are causing problems in
`JavaScript 2.0. One of the problems is that
`all var declarations inside a function are
`hoisted, which means that they take effect at
`the very beginning of the function even if
`the v a r declarations are nested inside
`blocks. Furthermore, duplicate var decla-
`rations are merged into one. This is fine for
`untyped variables, but what should happen
`for typed variables? What should the inter-
`pretation of the following function be?
`function f(a) {
` if (a) {
` var b:String = g();
` } else {
` var b:Number = 17;
` }
`}
`
`JavaScript 2.0: Evolving a Language for Evolving Systems
`
`7
`
` Exhibit 1027 Page 7
`
` SYMANTEC
`
`

`
`Using JavaScript 1.5 rules would interpret
`the function as the following, which would
`be an error because now b has two different
`types:
`function f(a) {
` var b:String;
` var b:Number;
` if (a) {
` b = g();
` } else {
` b = 17;
` }
`}
`
`JavaScript 2.0 also introduces the notion of
`const, which declares a constant rather
`than a variable. If b were a const instead
`of a var, then even if the two declarations
`had the same type then it would be undesir-
`able to hoist it:
`function f(a) {
` if (a) {
` const b = 5;
` } else {
` const b = 17;
` }
`}
`should not become:
`function f(a) {
` const b;
` if (a) {
` b = 5;
` } else {
` b = 17;
` }
`}
`For one thing, the latter allows b to be refer-
`enced after the end of the if statement.
`
`To solve these problems while remaining
`compatible with JavaScript 1.5, Java-
`Script 2.0 adopts block scoping with one
`exception: var declarations without a type
`and in non-strict mode (see below) are still
`hoisted to the top of a function. var decla-
`rations with a type are not hoisted, const
`declarations are not hoisted, and declarations
`in strict mode are not hoisted. To help catch
`errors, a block nested inside another block
`within a function may not redeclare a local
`
`variable. Moreover, if a block declares a lo-
`cal variable named x, then an outer block in
`the same function may not refer to a global
`variable named x. Thus, the following code
`is in error because the return statement is
`not permitted to refer to the global x:
`var x = 3;
`
`function f(a) {
` if (a) {
` var x:Number = 5;
` }
` return x;
`}
`
`5.1 Strict Mode
`Some of JavaScript 1.5’s quirks can’t be
`corrected without breaking compatibility.
`For these JavaScript 2.0 introduces the no-
`tion of a strict mode which turns off some of
`the more troublesome behavior. In addition
`to making all declarations lexically scoped,
`strict mode does the following:
`
`• Variables must be declared — mis-
`spelled variables no longer automati-
`cally create new global variables.
`• Function declarations are immutable
`(JavaScript 1.5 treats any function dec-
`laration as declaring a variable that may
`be replaced by another function or any
`other value at any time).
`• Function calls are checked to make sure
`that they provide the proper number of
`arguments. JavaScript 2.0 provides an
`explicit way of declaring functions that
`take optional, named, or variable
`amounts of arguments.
`• Semicolon insertion changes — line
`breaks are no longer significant in strict-
`mode JavaScript 2.0 source code. Line
`breaks no longer turn into semicolons
`(as
`they do
`in some places
`in
`JavaScript 1.5), and they are now
`allowed anywhere between two tokens.
`
`Strict and non-strict parts may be mixed
`freely within a program. For compatibility,
`the default is non-strict mode.
`
`JavaScript 2.0: Evolving a Language for Evolving Systems
`
`8
`
` Exhibit 1027 Page 8
`
` SYMANTEC
`
`

`
`6 Classes
`In addition to the prototype-based objects of
`JavaScript 1.5, JavaScript 2.0 supports class-
`based objects. Class declarations are best
`illustrated by an example:
`
`class Point {
` var x:Number;
` var y:Number;
`
` function radius() {
` return Math.sqrt(
` x*x + y*y);
` }
`
` static var count = 0;
`}
`
`A class definition is like a block in that it
`can contain arbitrary statements that are
`evaluated at the time execution reaches the
`class; however, definitions inside the class
`define instance (or class if preceded with the
`static attribute) members of the class in-
`stead of local variables. Classes can inherit
`from other classes, but multiple inheritance
`is not supported.
`
`Classes can co-exist with prototype-based
`objects. The syntax to read or write a prop-
`erty (object.property) is the same regardless
`of whether the object is prototype or class-
`based. By default, accessing a nonexistent
`property of a class instance is an error, but if
`one places the attribute dynamic in front
`of the class declaration then one can create
`new dynamic properties on that class’s in-
`stances just like for prototype-based objects.
`
`6.1 Rationale
`There are a number of reasons classes were
`added to JavaScript 2.0:
`
`• Classes provide stronger and more
`flexible abstractions than prototypes. A
`class can determine the pattern of mem-
`bers that each instance must have, con-
`trol the creation of instances, and control
`both its usage and overriding interfaces.
`Furthermore, a JavaScript 2.0 class can
`
`enforce these rules without cooperation
`from its clients, which allows well-con-
`structed classes to rely on their invari-
`ants regardless of what their clients do.
`• Classes provide a good basis for
`versioning and access control (sec-
`tion 7).
`• Prototype-based languages naturally
`evolve classes anyway by convention,
`typically by introducing dual hierarchies
`that include prototype and traits objects
`[1]. Placing classes in the language
`makes the convention uniform and en-
`forceable.8
`• Complexity of prototypes. Few scrip-
`ters are sophisticated enough to cor-
`rectly create a multi-level prototype-
`based hierarchy in JavaScript 1.5. In
`fact, this is difficult even for moderately
`experienced programmers.
`• The class syntax is much more self-
`documenting than analogous Java-
`Script 1.5 prototype hierarchies.
`• Classes as a primitive in the language
`provide a valuable means of reflecting
`other languages’ data structures in
`JavaScript 2.0 and vice versa.
`• Classes are one of the most-requested
`features in JavaScript.
`
`Introducing two means of doing something
`(classes and prototypes) always carries some
`burden of having to choose ahead of time
`which means to use for a particular problem
`and the subsequent danger of needing to re-
`cover from having made the wrong choice.
`However, it’s likely that at some point in the
`future most programmers will use classes
`exclusively and not even bother to learn
`prototypes. To make recovery easier, the
`syntax for routine usage of classes and pro-
`totypes is identical, so changing one to the
`other only requires changing the declaration.
`
`
`8 An earlier JavaScript 2.0 proposal actually reflected a
`class’s members via prototypes and traits objects and allowed
`any class instance to serve as a base for prototype inheritance
`and vice versa. That proposal was dropped because it made
`language implementation much more complex than desired
`and required the authors of classes to think about not only
`constructors but also cloners just in the rare case that a client
`used the classes’ instances as prototypes.
`
`JavaScript 2.0: Evolving a Language for Evolving Systems
`
`9
`
` Exhibit 1027 Page 9
`
` SYMANTEC
`
`

`
`7.3 Scenario
`Here’s an example of how such a collision
`can arise. Suppose that a package provider
`creates a package called BitTracker that
`exports a class Data. This package be-
`comes so successful that it is bundled with
`all web browsers produced by the Brows-
`ersRUs company:
`package BitTracker {
`
`class Data {
` var author;
` var contents;
` function save() {...}
`
`} f
`
`unction store(d) {
` ...
` storeOnFastDisk(d);
`
`}}
`
`Now someone else writes a client web page
`W that takes advantage of BitTracker.
`The class Picture derives from Data and
`adds, among other things, a method called
`size that returns the dimensions of the
`picture:
`import BitTracker;
`
`class Picture extends
` Data {
` function size() {...}
` var palette;
`};
`
`function orientation(d) {
` if (d.size().h >=
` d.size().v)
` return "Landscape";
` else
` return "Portrait";
`}
`
`The author of the BitTracker package,
`who hasn’t seen W, decides in response to
`customer requests to add a method called
`size that returns the number of bytes of
`data in a Data object. He then releases the
`new and improved BitTracker package.
`
`To keep the language simple, there is no no-
`tion of Java-like interfaces. Unlike in Java,
`these are not necessary for polymorphism
`because JavaScript 2.0 is dynamically typed.
`
`7 Namespaces, Versioning,
`and Packages
`
`7.1 Packages
`A JavaScript 2.0 package is a collection of
`top-level definitions declared inside a
`package statement. An import statement
`refers to an existing package and makes the
`top-level definitions from that package
`available. The exact scheme used to name
`and locate existing packages is necessarily
`dependent on the environment in which
`JavaScript 2.0 is embedded and will be de-
`fined and standardized independently as
`needed for each kind of embedding (brows-
`ers, servers, standalone implementations,
`etc.).
`
`7.2 Versioning Issues
`As a package evolves over time it often be-
`comes necessary to change its exported in-
`terface. Most of these changes involve add-
`ing definitions (top-level or class members),
`although occasionally a definition may be
`deleted or renamed. In a monolithic envi-
`ronment w