Merge pull request #1049 from asciidwango/publish1

【Ecmascript】用字用語の統一・編集済み

source/basic/ecmascript/README.md

@@ -5,11 +5,11 @@ description: "JavaScriptの仕様であるECMAScriptについてを紹介しま
 
 # ECMAScript {#ecmascript}
 
-ここまでJavaScriptの基本文法について見ていきましたが、その文法を定めるECMAScriptという仕様自体がどのように変化していくのかを見ていきましょう。
+ここまでJavaScriptの基本文法について見てきましたが、その文法を定めるECMAScriptという仕様自体がどのように変化していくのかを見ていきましょう。
 
 ECMAScriptは[Ecma International][]という団体によって標準化されている仕様です。
 Ecma InternationalはECMAScript以外にもC#やDartなどの標準化作業をしています。
-Ecma Internationalの中のTechnical Committee 39（TC39）という技術委員会が中心となって、ECMAScript仕様についてを議論しています。
+Ecma Internationalの中のTechnical Committee 39（TC39）という技術委員会が中心となって、ECMAScript仕様について議論しています。
 この技術委員会はMicrosoft、Mozilla、Google、AppleといったブラウザベンダーやECMAScriptに関心のある企業などによって構成されます。
 
 ## ECMAScriptのバージョンの歴史 {#history}
@@ -32,30 +32,30 @@ Ecma Internationalの中のTechnical Committee 39（TC39）という技術委員
 <!-- textlint-disable -->
 
 ES5.1からES2015がでるまで4年もの歳月がかかっているのに対して、ES2015以降は毎年リリースされています。
-毎年安定したリリースを行えるようになったのは、ES2015以降は仕様策定プロセスの変更が行われたためです。
+毎年安定したリリースを行えるようになったのは、ES2015以降に仕様策定プロセスの変更が行われたためです。
 
 <!-- textlint-enable -->
 
 
 ## Living StandardとなるECMAScript {#living-standard}
 
-現在、ECMAScriptの仕様書のドラフトはGitHub上の[tc39/ecma262][]で管理されており日々更新されています。
+現在、ECMAScriptの仕様書のドラフトはGitHub上の[tc39/ecma262][]で管理されており、日々更新されています。
 そのため、本当の意味での最新のECMAScript仕様は<https://tc39.github.io/ecma262/>となります。
-このように更新ごとにバージョン番号を付けずに、常に最新版を公開する仕様のことを**Living Standard**と呼びます。
+このように更新ごとにバージョン番号をつけずに、常に最新版を公開する仕様のことを**Living Standard**と呼びます。
 
 ECMAScriptはLiving Standardですが、これに加えてECMAScript 2017のようにバージョン番号をつけたものも公開されています。
-このバージョン付きECMAScriptは、毎年決まった時期のドラフトを元にしたスナップショットのようなものです。
+このバージョンつきECMAScriptは、毎年決まった時期のドラフトを元にしたスナップショットのようなものです。
 
 ブラウザなどに実際にJavaScriptとして実装される際には、Living StandardのECMAScriptを参照しています。
-これは、ブラウザ自体も日々更新されるものであり、決まった時期にしかリリースされないバージョン付きよりもLiving Standardの方が適当であるためです。
+これは、ブラウザ自体も日々更新されるものであり、決まった時期にしかリリースされないバージョンつきよりもLiving Standardのほうが適当であるためです。
 
 ## 仕様策定のプロセス {#specification-process}
 
-ES2015以前はすべての仕様の合意が取れるまで延々と議論を続けすべてが決まってからリリースされていました。
-そのため、ES2015がリリースされるまでには長い時間がかかり言語の進化が停滞していました。
+ES2015以前はすべての仕様の合意が取れるまで延々と議論を続け、すべてが決まってからリリースされていました。
+そのため、ES2015がリリースされるまでには長い時間がかかり、言語の進化が停滞していました。
 この問題を解消するために、TC39は毎年リリースする形へとECMAScriptの策定プロセスを変更しました。
 
-この策定プロセスはES2015がリリース後に適応され、このプロセスで初めてリリースされたのがES2016となります。
+この策定プロセスはES2015のリリース後に適用され、このプロセスで初めてリリースされたのがES2016となります。
 ES2016以降では、次のような仕様策定のプロセスで議論を進めて仕様が決定されています。[^2]
 
 仕様に追加する機能（API、構文など）をそれぞれ個別の**プロポーザル**（提案書）として進めていきます。
@@ -68,7 +68,7 @@ ES2016以降では、次のような仕様策定のプロセスで議論を進
 |    1     | 機能提案の段階                                               |
 |    2     | 機能の仕様書ドラフトを作成した段階                               |
 |    3     | 仕様としては完成しており、ブラウザの実装やフィードバックを求める段階  |
-|    4     | 仕様策定が完了し、2つ以上の実装が存在している。<br />正式にECMAScriptにマージできる段階 |
+|    4     | 仕様策定が完了し、2つ以上の実装が存在している<br />正式にECMAScriptにマージできる段階 |
 
 2ヶ月に一度行われるTC39のミーティングにおいて、プロポーザルごとにステージを進めるかどうかを議論します。
 このミーティングの議事録もGitHub上の[tc39/tc39-notes][]にて公開されています。
@@ -82,48 +82,47 @@ ES2016以降では、次のような仕様策定のプロセスで議論を進
 その他のクラスの機能は別のプロポーザルとして提案され、ES2015以降に持ち越された形で議論が進められています。
 
 このような合意が取れる最低限の形でプロポーザルを進めていくのには、ES4の苦い失敗が背景にあります。
-ES4ではECMAScriptに多くの変更を入れることを試みましたが、TC39内でも意見が分かれ最終的に合意できませんでした。
-これによりES4の策定に割いた数年分のリソースが無駄となってしまったという経緯があります。[^3]
+ES4ではECMAScriptに多くの変更を入れることを試みましたが、TC39内でも意見が分かれ、最終的に合意できませんでした。
+これによりES4の策定に割いた数年分のリソースが無駄になってしまったという経緯があります。[^3]
 
 ES2016以降の策定プロセスでも、すべてのプロポーザルが仕様に入るわけではありません。[^4]
-別の代替プロポーザルが出た場合や後方互換性と保てない場合などにプロポーザルの策定を中断する場合があります。
+別の代替プロポーザルが出た場合や後方互換性を保てない場合などにプロポーザルの策定を中断する場合があります。
 しかし、この場合でもプロポーザルという単位であるため策定作業の無駄は最小限で済みます。
 このようにモジュール化されたプロポーザルは入れ替えがしやすいという性質もあります。
 
 ## プロポーザルの機能を試す {#try-proposal}
 
 ECMAScriptの策定プロセスのステージ4に「2つ以上の実装が存在している」という項目があります。
 そのためブラウザのJavaScriptエンジンには、策定中のプロポーザルが実装されている場合があります。
-多くの場合は試験的なフラグ付きで実装されておりフラグを有効化することで、試すことができるようになっています。
+多くの場合は試験的なフラグつきで実装されておりフラグを有効化することで、試すことができるようになっています。
 
 またTranspilerやPolyfillといった手段で、プロポーザルの機能をエミュレートできる場合があります。
 
 Transpilerとは、新しい構文を既存の機能で再現できるようにソースコードを変換するツールのことです。
 たとえば、ES2015で`class`構文が導入されましたが、ES5では`class`は予約語であるため構文エラーとなり実行できません。
-Transpilerでは、`class`構文を含むソースコードを`function`キーワードを使い疑似的に再現するコードへ変換します。
+Transpilerでは、`class`構文を含むソースコードを`function`キーワードを使って疑似的に再現するコードへ変換します。
 Transpilerとしては[Babel][]や[TypeScript][]などが有名です。
 
 Polyfillとは、新しい関数やメソッドなどの仕様を満たすような実装を提供するライブラリのことです。
 たとえば、ES2016では`Array#includes`というメソッドが追加されました。
 構文とは異なり`Array#includes`のようなメソッドはビルトインオブジェクトを書き換えることで実装できます。
 Polyfillを提供するものとしては[core-js][]や[polyfill.io][]などが有名です。
 
-注意点としてはTranspilerやPolyfillは、あくまで既存の機能を用いて新しい機能の再現を試みているだけに過ぎません。
+注意点としてはTranspilerやPolyfillは、あくまで既存の機能を用いて新しい機能の再現を試みているだけにすぎません。
 そのため、既存の機能で再現ができないプロポーザル（機能）はTranspilerやPolyfillでは再現できません。
 また、完全な再現はできていないことがあるためTranspilerやPolyfillを新しい機能を学ぶために使うべきではありません。
 
 <!-- Notes: バージョンが西暦となった理由
 
 実際に各ブラウザなどはECMAScriptを実装していますが、このときに参照するのは基本的にLiving StandardであるECMAScriptです。
-また、PolyfillやTranspilerといった手段で、タグ付けされたECMAScript 20XXがリリースされる前にその機能が利用できることも多いです。
+また、PolyfillやTranspilerといった手段で、タグづけされたECMAScript 20XXがリリースされる前にその機能が利用できることも多いです。
 ECMAScriptのバージョンとしてES6ではなくES2015のように西暦をバージョンとして使うようになったのも、Living Standardを意識しての試みです。
 
 -->
 
 ## 仕様や策定プロセスを知る意味 {#meaning-specification-process}
 
-こうしたECMAScriptという仕様や策定プロセスを知る意味は何があるのでしょうか？
-主に次のような理由で知る意味があると考えています。
+こうしたECMAScriptという仕様や策定プロセスを知る意味は何があるのでしょうか？　主に次のような理由で知る意味があると考えています。
 
 - 言語を学ぶため
 - 言語が進化しているため
@@ -146,10 +145,10 @@ ECMAScriptは後方互換性を尊重するため、今学んでいることが
 しかしながら言語自体も進化していることは意識しておくとよいでしょう。
 
 ECMAScriptのプロポーザル（機能）は問題を解決するために提案されます。
-そのプロポーザルがECMAScriptにマージされ利用できる場合、その機能が何を解決するために導入されたのか知ることは大切です。
-その際には、ECMAScriptの策定プロセスを知っておくことが調べることに役立ちます。
+そのプロポーザルがECMAScriptにマージされ利用できる場合、その機能が何を解決するために導入されたのかを知ることが大切です。
+その際には、ECMAScriptの策定プロセスを知っておくことが役立ちます。
 
-この仕様はなぜこうなったのかということを知りたいと思ったときに、その機能がどのような経緯で入ったのかを調べる手段をもつことは大切です。
+この仕様はなぜこうなったのかということを知りたいと思ったときに、その機能がどのような経緯で入ったのかを調べる手段を持つことは大切です。
 特にES2015以降は策定プロセスもGitHubを利用したオープンなものとなり、過去の記録なども探しやすくなっています。
 
 ### 情報の正しい状態を調べるため {#to-search}
@@ -158,25 +157,25 @@ JavaScriptは幅広く使われている言語であるため、世の中には
 そして、検索して見つかる情報には正しいものや間違ったものが混在しています。
 
 その中においてECMAScriptの仕様やその策定中のプロポーザルに関する情報は状態が明確です。
-基本的にECMAScriptの仕様に入ったものは、後方互換性を維持するために破壊的変更はほとんど行なえません。
-プロポーザルはステージという明示された状態があり、ステージ4未満の場合はまだ安定していないことが分かります。
+基本的にECMAScriptの仕様に入るものは、後方互換性を維持するために破壊的変更はほとんど行えません。
+プロポーザルはステージという明示された状態があり、ステージ4未満の場合はまだ安定していないことがわかります。
 
-そのため、問題を見つけた際に該当する仕様やプロポーザルを確認してみることは重要です。
+そのため、問題を見つけた際に該当する仕様やプロポーザルを確認してみることが重要です。
 
-これはECMAScriptにかぎらず、ウェブやブラウザに関する情報に関しては同じことがいえます。
+これはECMAScriptに限らず、ウェブやブラウザに関する情報については同じことが言えます。
 ブラウザに関してはHTML、DOM API、CSSなどのオープンな仕様とそれぞれの策定プロセスが存在しています。
 
 ### まとめ {#ecmascript-summary}
 
-JavaScriptと一言にいってもECMAScript、ウェブブラウザ、Node.js、WebAssembly、WebGL、WebRTCなど幅広い分野があります。
-そのためすべてのことを知っている必要はありませんし、知っている人もおそらくいないでしょう。
+JavaScriptと一言に言ってもECMAScript、ウェブブラウザ、Node.js、WebAssembly、WebGL、WebRTCなど幅広い分野があります。
+すべてのことを知っている必要はありませんし、知っている人もおそらくいないでしょう。
 このような状況下においては知識そのものよりも、それについて知りたいと思ったときに調べる方法を持っていることが大切です。
 
 何ごとも突然まったく新しい概念が増えるわけではなく、ものごとには過程が存在します。
 ECMAScriptにおいては策定プロセスという形でどのような段階であるかが公開されています。
 つまり、仕様にいきなり新しい機能が増えるのではなくプロポーザルという段階を踏んでいます。
 
-日々変化しているソフトウェアにおいては、自身に適切な調べ方をもつことが大切です。
+日々変化しているソフトウェアにおいては、自身に適切な調べ方を持つことが大切です。
 
 [Ecma International]: http://www.ecma-international.org/  "Ecma International"
 [Standard ECMA-262]: https://www.ecma-international.org/publications/standards/Ecma-262.htm "Standard ECMA-262"