InfoQ

InfoQ

News

マイブックマーク

ブックマークするためにログイン または 会員登録 する

ブックマークされました!

ブックマークがエラーになりました。もう一度お願いします。

ECMAScript 5リリース

作者 Alex Blewitt , 翻訳者 徳武 聡 投稿日 2009年12月13日

セクション
運用/インフラ,
デベロップメント
トピック
JavaScript ,
Java

原文(投稿日:2009/12/09)へのリンク

ECMAScript 5の仕様がが今週、リリースされた(pdf)。ECMAScriptは一般的にはJavaScript™として知られている。最新バージョンでは、基本ライブラリに改善が加えられている一方、一般的でありがちなコーディングミスを特定し、除去するためにより厳格なランタイムモードが導入された。

ECMAScript 4を合理化しようという初期の試みは大失敗に終わった。結局、Adobe社のActionScriptだけが提案された変更点に対応しただけだった。ECMAはバージョン4の仕様もリリースできなかった。バージョン4の仕様では、様々なグループの実装に悪影響を与えてしまうからだ。また、そのような問題がある限り、ブラウザもサポートできない。

ここ数年にわたって、JavaScriptのエンジンに大規模な改善が加えられた。例えば、NitroTraceMonkeyなどだ。その結果、JavaScriptはコラボレーションツールの分野で利用できるほど高性能になった。例えば、Google Waveはそのようなオンラインアプリケーションの事例のひとつだ。また、最近リリースされたGWT 2.0の一部としてSpeed TracerというGoogle Chromeの拡張がある。これは、JavaScriptのアプリケーションの性能を最適化するツールだ。

近年のこのような状況をふまえ、ECMAScript 5は現在使われているバージョン3との後方互換性の確保を目指し(各ブラウザが素早く対応できるようにするために)、同時に開発者が一般的なコーディングミスを犯さないようにするために、より厳しい制約を提供する。

Strict mode

strict modeを導入する目的は、ECMAScriptアプリケーションを開発するときに発生するコーディング上の一般的な問題を避けることだ。ひとつのユニット(スクリプトまたはファンクション)の中に、次のような文字列リテラルを書くことでこの制約を有効にできる。

"use strict;"

このリテラルは従来のランタイム上では何の影響もないが、バージョン5がターゲットとする新しいランタイム上ではstrict modeに切り替わる。スクリプトのトップに記述すればそのスクリプト全体が、ひとつのファンクションに記述すればそのファンクションが、strict modeになる。したがって、strict modeを適用したコードとそうでないコードを混在させることができ、既存のコードの改善にも利用できる。では、strict modeにすると実際にはどうなるのだろう。

  • 変数は利用する前に宣言しなくてはならない。言い換えれば、i=3という書き方はランタイムエラーになる。var i=3としなければならない。(iがこのスコープ内にはないという前提)
  • Evalは予約語になる。また、eval内で新しい変数を導入できなくなる。したがって、eval("var i=3"); print(i);と書くと例外が発生する。
  • 8進数のリテラルは使えない。したがって010は10であり、8ではない。
  • configurableフラグがfalseに設定されている引数や関数、変数やその他の属性に対して、delete演算子が使えない。
  • はエラーの原因になりやすいwithステートメントは使えない。構文エラーと見なされる。
  • 同じ名前で引数が重複しているファンクションは定義できない。
  • オブジェクトは同じ名前の属性を持てない。
  • argumentscaller変数は不変になる。
  • グローバルオブジェクトへのアクセスはランタイムエラーになる。

ライブラリの拡張

基本ライブラリに対して、次のような拡張が加えられている。

  • DateがISO8601形式の日付を生成できるようになる(例えば20091209T12:34:56Z)。パースもできる。
  • Stringにtrim()メソッドが組み込まれる。
  • 新しいJSONオブジェクトは、JSON形式のデータを効率的に生成するためにparsestringifyをサポートする。evalと似ているが、セキュリティを考慮した実装がないのでコードを少なくできる。加えて、RFC 4627に仕様化されているJSONObjectJSONArrayだけでなく、どのようなJSONValueも使える。(4627はJSON-Textを定義しているが、これはオブジェクトか配列に制限されている。)
  • Prototypeのbind()と同じ構文でbindが組み込まれた
  • Arrayが標準的なファンクションをサポートするようになる。例えばindexOf()map()filter()そして reduce()など。
  • オブジェクトはseal()(新しい属性の追加と既存の属性の削除ができなくなる)とfreeze()(すべての属性が読み取り専用になり、属性の追加と削除もできなくなる)が利用できる。
  • Object.keys()を使うとそのオブジェクトのすべてのenumerableな属性を一覧できる。
  • Object.getOwnPropertyNames()を使うとすべてのenumerableと非enumerable属性を一覧できる。
  • Object.getPrototypeof()を使うとそのオブジェクトのprototypeを返す。

要約

JSONのパース機構の標準サポートとstrict modeは開発者に多大な恩恵を与える。これらの機能を使えばPrototypeや必要な拡張ライブラリのためにコードをより小さなライブラリへ変換できる可能性がある。JSONストリームからISO形式にパースされた日付は以前よりもはるかに移植が簡単になる。将来は日付を表す形式のデファクトスタンダードになるだろう。また、後方互換性が確保され、Prototypeのような既存のライブラリからヒントを得ているので、比較的近い将来のうちに開発者やブラウザは新しいJavaScriptの特徴になじむだろう。

特集コンテンツ一覧

GAE開発の落とし穴

Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します

イベントレポート:「Coqチュートリアル#1」

去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。

Javaの未来についてのNeal Gafter氏とのディスカッション

Choosing Options

Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。

Google Dartのエッセンス:アプリケーションの構築、スナップショット、Isolate

GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式

CSPベースのモデル検査ツール「Process Analysis Toolkit」

本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。

Jenkinsによる継続的インテグレーションのススメ(4) ~CloudBeesでJenkinsをサービスとして使う~

前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。

書籍『抽象によるソフトウェア設計-Alloyではじめる形式手法-』の紹介

Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。

Windows デバイスで開発するタッチユーザーインターフェイス

スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。