15. ES4 テイク 1

TC39 では最初の会合 ── Borland International [1996] がクラスを定義する機能の追加を提案した会合 ── から、大規模なプログラムの複雑性を管理するのに役立つ機能を JavaScript に追加することへの関心は存在した。Netscape の JavaScript 1.2 は暗号学的署名付きスクリプトと import と export の宣言を通じたそれらの統合をサポートした [Netscape 1997a]。また Microsoft の JScript 3 は条件付きコンパイルの機能を持っていた [Clinick 1997]。1998 年 2 月バージョンの ECMAScript 機能リスト [TC39 1998c] は「パッケージの概念」を V2 で追加される可能性がある要素として挙げている。こういった大規模プログラミング用の機能は比較的早期に ES3 の機能セットから取り除かれたものの、TC39 内での取り組みは続いた。

一つ目の重要な提案は Hewlett-Packard がスポンサーの W3C フェロー Dave Raggett からのものである。W3C において、Raggett は HTML, CSS, JavaScript の統合を改善する「Spice」と呼ばれる言語の提案を作成していた。この提案の初期バージョン [Raggett 1998c] は 1998 年 2 月に TC39 へ提出された。Raggett の初期提案には HTML と CSS を統合する機能に加えてプロトタイプオブジェクトを宣言する構文が含まれており、これは Borland の class 宣言の提案に似ていた。この構文はイベントハンドラをプロトタイプオブジェクトへ宣言的に関連付ける機能を追加する。Raggett の提案には「ライブラリ」を定義するための構文とライブラリから定義をインポートする構文も含まれていた。次のようなものである:

import document, block, Inline from "http://www.w3.org/Style/std.lib";
prototype Link extends Inline
{
   href = "http://www.w3.org/";
   when onmousedown
   {
      document.load(this.href);
   }
}

1998 年 3 月会合の報告書 [TC39 1998d] には、Dave Raggett が提出した Spice の初期提案の議論が行われ、「初期フィードバックは否定的だった」とある。Raggett は HP Labs の言語設計者 Chris Dollin と Steve Leach と共に自身の提案を発展させ、11 月には拡張された Spice の提案を説明した新しい文書一式 [Raggett et al. 1998] を提出した。これは事実上、ECMAScript を非互換な形で置き換える言語の提案だった ── 波括弧で区切られた C 風の構文を終端キーワードベースの文構文で置き換えてさえいた。

Dave Raggett [1998a] は改訂された Spice の提案を 1998 年 11 月の TC39 ワーキンググループの会合で提出した。同月にはこれに先立って Netscape と Microsoft の TC39 代表者と Spice 設計者の間でプライベートな会合が行われていた。ワーキンググループの会合で TC39 のメンバーは、当時の文の構文を置き換えたりスタイルシートに対する宣言的サポートを即座に取り入れたりすることには関心を抱かなかった。しかし、クラス、数値単位¹、型、モジュールといった Spice 提案の一部を利用して ECMAScript を拡張することに関しては前向きな意見があった。Raggett は質問への答えとして、もし ECMAScript に同じような機能が追加されたら HP が Spice の開発を続けることはないだろうと述べた²。

TC39 内に Spice ワーキンググループが新しく設立され、1999 年 1 月にグループ全体へ示すための提案を作成することになった。新しいコア概念をサポートするための新しい機能は既に予約済みの Java キーワードを使って定義され、クラスの意味論は Java に近いものになるだろうと TC39 は予想していた。数値単位はクラスを使って定義され、加算の演算子オーバーロードが必要になるだろうとも思われていた。

Spice ワーキンググループの初回通話会議は 1998 年 12 月の第 1 週に開催され、12 月 10 日には Dave Raggett [1998b] がその会議に基づく新しい文書を配布した。この文書はパッケージと数値単位にも軽く触れているものの、より詳しく説明されたのはクラスとインターフェースの定義を含む型宣言についてだった。焦点は意味論よりも構文に当たっている。Raggett の文書は名前的型システム^語を仮定しており、この型システムには名前の付いた組み込みプリミティブ型、同質配列型、サブクラスが名前的部分型となるようなクラス型、インターフェース型、そしてアクセスで動的な型検査が必要な any 型が存在した。変数束縛に型を関連付ける構文の選択肢が調査されており、変数宣言には var キーワードが使われ続けるという仮定の下で、型情報を宣言される名前の前に付ける C スタイルの構文と型情報を宣言される名前の後に付ける Pascal スタイルの構文が示されている。二つの選択肢を図 24 に示す。

// C スタイルの型宣言
var float x, int[] y, z;       // z の型は？
var float x, int[] y, int[] z; // こうか？
var float x, int[] y, any z;   // それともこっちか？

// Pascal スタイルの型宣言
var x: float, y: int[], z;      // z の型は any になる

クラスとインターフェースを定義する構文は Java に多少似ており、public, private, protect に対応する機能とデフォルトの可視性 (パッケージ全体) を変更する機能を持っていた。内部のメタオブジェクト構造については言及がなく、Spice のメタオブジェクトのモデルが当時の JavaScript が採用するプロトタイプ継承モデルと異なることは暗黙の了解とされた。またこの文書では、宣言された静的型を使った事前束縛のメンバーアクセスと静的な型情報が存在しない事後束縛のメンバーアクセスを区別しなければならないという問題が指摘されている。動的にプロパティを追加すること³についても考察され、これを無効化する機能をクラスに持たせるのが望ましいだろうとしている。

クラス、型注釈^語、スコープを主な議題とした設計議論が 1999 年の 1 月から 2 月にかけて続いた [Raggett 1999b, c]。主な参加者には Chris Dollin, Waldemar Horwat, Herman Venter がいた。議論のほとんどはクラスで定義されたオブジェクトの性質およびクラスメンバーアクセスの意味論についてだった。Dollin と Venter はクラスインスタンスの構造がクラス宣言から静的に決定し、メンバーへのアクセス可能性が参照する側で利用可能な型情報から静的に決定する Java 風の意味論を基本的には使うべきだと考えた。一方 Horwat は型注釈が存在する場合でもメンバーへのアクセスでは失敗の可能性がある動的なルックアップを使うべきだと考えた。省略可能な型注釈、expando プロパティ、既存の JavaScript プログラマの期待、そしてプロトタイプベースのアドホックなクラスを使う既存のコードとの互換性のどれを考えても、もっと動的な意味論が必要なように思えたためである。加えて、複数のソースからコードを動的に組み立てたり、ライブラリの開発がそれを参照するコードと独立して行われたりする JavaScript というスクリプト言語の性質には動的な意味論が合っていると Horwat は論じた。Horwat [1999b] はメンバールックアップの選択肢を説明する文書で静的なアプローチと動的なアプローチの違いをまとめている。

2 月の会合で Waldemar Horwat [1999a] は自身が用意した「JavaScript 2.0」の仕様を披露した。彼は JavaScript 2.0 を Netscape のための実験的な設計⁴と位置付け、TC39 における最近の議論を反映させた⁵。JavaScript 2.0 にはマシンレベルの数値型の大きな集合を持つ名前的型システム、Java 風のクラスメンバー可視性規則、明示的な import を持つパッケージシステムが含まれる。他にも色々な新機能があり、例えばクラス拡張宣言、パッケージのメンバーに対する宣言レベルのバージョン付け、nullable 型と非 nullable 型、ファーストクラスの型値が存在した。JavaScript 2.0 は以前の JavaScript と同じ「宣言を巻き上げる」意味論を採用せず、実行の流れが到達するまで宣言が処理されない「ストリーミング実行モデル」を提案した [Raggett 1999d]。例えば if 文を使って特定の条件が成り立つときだけ変数を宣言したり、複数の型から一つを選択して宣言に型注釈として付加したりできる。ファーストクラスの型値と宣言のストリーミング実行の組み合わせにより、一部のケースでは完全な静的型検査が不可能だった。

JavaScript 2.0 はオリジナルの JavaScript と完全な後方互換性を持たない。それどころか、当時未完成の ECMAScript 3 とさえ互換でない。JavaScript 2.0 を TC39 に紹介するとき Waldemar Horwat は「少なくとも ECMAScript 1.0 [ES3] と 2.0 [ES4] の両方で動作するコードを書くことはできるはずだ。ただ完全な後方互換性は骨が折れるだろう」と述べている [Raggett 1999c]。例えば省略可能な型注釈によって構文が複雑になり、改行におけるセミコロンの自動的な挿入はサポートできなくなる。Horwat が示した後方互換性への解決策は、実装が複数のコンパイラを提供するというものだった。彼は言語のバージョンに応じてコンパイラを切り替える方が厳密な前方互換性を保ちながら単一の言語を開発するより優れると主張した。

1999 年の残りでは ES3 を完成させることに TC39 の労力のほとんどが注がれたものの、3 月には ES3 より後に追加される可能性のある機能をまとめた「機能リスト」が作成された [TC39 1999c]。Spice ワーキンググループはモジュール化機能サブグループに名前を変え、折に触れて顔を合わせて ES4₁ について議論した [Raggett 1999a; TC39 1999a]。11 月になって TC39 の主な関心が「第 4 版」に移ると議論のペースが速まり、ES3 より後に追加される可能性のある機能リストが更新された (図 25)。1999 年 11 月に作成された TC39 議長による報告書 [Lewis 1999a] は ES4₁ の目標を説明している:

ECMAScript 2.0 [ES4] は大きく改善された野心的な ECMAScript 言語定義であり、[TC39 は] 標準化を 2000 年内に行いたいと考えている (ただこれは野心的すぎるかもしれない)。ECMAScript 2.0 の主な目標は「大規模プログラミング」のサポートを提供すること ── つまり、複数人によって別々に書かれユーザーのデスクトップで (おそらくは初めて) 組み立てられるプログラムの構築をサポートすることである。

Microsoft は 2000 年 1 月の会合 [Raggett 2000] で、機能を削って第 4 版の公開日を 2000 年 12 月にすることを強く主張した。Microsoft の主な関心は静的型注釈を追加しつつも自動的なセミコロン挿入のサポートを含めた後方互換性の維持することにあった。Venter は型注釈をサポートするために彼が必要だと考えた ES3 仕様への変更のまとめを配布した。しかしクラス、パッケージ、名前空間の意味論、型システムの性質、そして一つの言語に静的な要素と動的な要素を共存させる方法は不確かなままだった。

2000 年 6 月 22 日、Microsoft [2000b] は .NET Framework を発表する。これは Sun の Java プラットフォームに Microsoft が対抗したものである。最重視した C# という言語に加えて、.NET は Visual Basic の方言や JavaScript などの言語もサポートした。発表の後 7 月には Microsoft の Professional Developer's Conference で .NET のプレビュービルドがリリースされた⁶ [Microsoft 2000a]。このプレビューには JScript .NET [Clinick 2000] の初期バージョンが含まれていた。ブラウザの JavaScript と異なり JScript .NET は .NET 共通言語ランタイム (Common Language Runtime, CLR) への事前コンパイルが行われる言語で、内部では .NET の型システムを利用する。Internet Explorer は JScript .NET (および一般に .NET) をサポートせず、その代わり JScript .NET では様々な .NET フレームワークコンポーネントを利用したデスクトップ用、サーバー用、コマンドライン用アプリケーションの構築が最初から可能だった。JScript .NET は ES3 仕様との互換性をアピールしていたものの、ブラウザでの実行を意図して書かれた JavaScript を実行するわけではないので、後方互換性は大きな問題ではなかった。JScript .NET は ES3 の機能に加えて省略可能な静的型注釈、メンバーの可視性を指定する属性を持つクラスとインターフェースの宣言、そして明示的な import を持ったパッケージシステムを持っていた。Microsoft の Andrew Clinick は JScript .NET の発表記事 [Clinick 2000] で新しい機能は他の Ecma TC39 メンバーと共に設計されたものだと述べ、TC39 で進行中の議論に基づいて設計の詳細が変更される可能性があると警告している。

2000 年 6 月に .NET が発表されるまで、Microsoft の Herman Venter は .NET あるいは JScript .NET について Waldemar Horwat をはじめとした他の TC39 メンバーと議論できなかった。8 月、Horwat と Venter はプライベートに接触し、ES4 規格の完成を可能にするための調整について話し合った。Horwat [2000] による議論の報告書には合意に至らなかった問題点や意見が 43 個記録され、議論が次のようにまとめられている:

概要: Herman [Venter] はサーバー向け JScript 実装を準備しており、言語を凍結して Microsoft .NET ランタイムとの相互運用性を高めることを望んでいる。Waldemar [Horwat] は JavaScript のブラウザへの適用性、および彼が JavaScript の差別化要因と考える動的性が失われることを憂慮している。彼は JavaScript が Java や C# に向かっていることに懸念を表明した。というのも、そういった空間に新しい言語の必要性はほとんど存在せず、仮に作ったとしても静的プログラミングは C# に劣るものになると彼は考えているからである。Herman は新しいサーバープロジェクトでは JScript ではなく C# を使うことを推奨し、新しい JScript を JScript でのプログラミングに既に慣れている開発者のために作られた言語とみなしている。

Horwat [2003a] は JavaScript 2.0 の文書をフォークして ECMAScript 4 Netscape Proposal という個別の文書を作成した。この文書は進行中だった ES4₁ の作成で作業ドラフトとして利用された。JavaScript 2.0 の文書は並行して管理され続け、ここには TC39 が取り入れることにまだ合意していない追加機能も追加された。

Microsoft は .NET と .NET に対応する言語が規格に基づく技術であると認識されることを望んだ。Ecma はプロプライエタリな技術を容易に標準化過程に載せられる組織という評判があり、Microsoft は TC39 による標準化の手法に満足していた。そこで Microsoft は TC39 の対象範囲を拡大し、その上で .NET を TC39 で標準化することを提案した。これを受けて TC39 は「プログラミング環境」に対する Ecma 技術委員会として再設立された。進行中の ECMAScript 関連の活動は TC39-TG1 と呼ばれる TC39 内の作業部会が担当することになり、加えて CLR と C# の規格を作成する別の TC39 作業部会も設立された。

ECMAScript 仕様の第 4 版を作成する作業はこの後 3 年にわたって続いた。しかし後になって考えると、JScript .NET の発表はこの取り組みの終わりの始まりだった。2000 年 6 月には Netscape は「ブラウザ戦争」に敗北し [Borland 2003]、Netscape のマーケットシェアは 14% を下回っていた [Reuters 2000]。America Online に買収された後 Netscape はスタッフを失い、活動リソースは削減され、新しいバージョンのブラウザを出荷するのに苦労していた。

Microsoft は Internet Explorer でブラウザ戦争に勝利し、最終的に 90% 以上のマーケットシェアを達成した。Microsoft はプロプライエタリにコントロールできないウェブプログラミングプラットフォームをさらに改善することに関心を持たず、内部のリソースは ECMAScript といったオープンなブラウザ技術の改善から Windows Presentation Framework⁷ といったプロプライエタリな Microsoft 技術の開発に移されていった。こうすることでプロプライエタリな技術が最終的にオープンな技術を潰して置き換えることを Microsoft は期待していた。.NET 用のプログラミング言語の領域では C# と Visual Basic .NET にリソースが注がれた。この文脈で言えば、JScript .NET には JavaScript プログラマが .NET プラットフォームに移行できるようにする以上の意味はなかった。

TG1 は会合を開いて個別の問題を議論し、仕様のドラフトを更新し続けた⁸。型システムの性質について Microsoft と Netscape の意見は激しく対立した。Waldemar Horwat は MIT の軽量言語ワークショップで JavaScript 2.0 の設計に関する論文 [Horwat 2001] を発表し、JavaScript 2.0 を「強い動的型付け」を持つ言語と特徴付けた。さらに JavaScript 2.0 では全ての変数に格納できる値を制限する型が関連付くものの、型に関する制約の確認は実行時に行う必要があると彼は説明した。JavaScript 2.0 が持つファーストクラスの型値と暗黙のダウンキャスト⁹により、プログラムを静的に型検査することが一般には不可能になる。

TG1 会合の頻度と参加者数は少しずつ減少していった。Chris Dollin が最後に参加したのは 2001 年 6 月で、Herman Venter が最後に参加した TC39-TG1 会合は 2002 年 6 月である。America Online は 2003 年 7 月 15 日 に Netscape の解散と Waldemar Horwat を含むほとんどの従業員のレイオフを発表した。同じ週に開かれた TG1 会合で Horwat は ES4 編集者を退任した。残された TG1 のメンバーは ECMAScript における XML サポートの策定に労力を集中させ、XML プロジェクトが完了して新たな編集者が見つかるまで ES4 の取り組みを停止することを決定した。