Layzie/JavaScript-Garden — Issue #1: 日本語訳で気が付いた点のまとめ
Author: shigeki
Created: 2011-11-14 07:25:11+00:00
State: open

JavaScript Garden の日本語訳の作成、本当にご苦労様です。
訳を読んでみて気が付いたところを英文と照らし合わせて記載させていただきました。
翻訳の素人なのでなかなかこなれた日本語にするのは難しいですが、原文と意味が違うのではないかと思われるところを中心にして書きました。
行ポインターとか指定が難しいので原文 → 修正案文 の形をとらせていただいています。 よろしければ内容を確認の上、反映していただければ幸いです。

*** 関数 ***
この場合thisの代わりにundefined値を持つことになります。
→ この場合 this は undefined値を（グローバルオブジェクトの）代わりに持つことになります。

これらほとんどのケースで見てきたように、最初のケースでは絶対に実用化できないという言語設計のミスを考慮しないとなりません。
→ これら（５つの）ケースのほとんどは理にかなったものだが、（this がglobalを指すという）最初のケースは実用的に利用されることが絶対にないので、間違った言語設計であるとみなせる。

この中のthisは、最早someobjectを参照できなくなってしまいます。
→ この中のthisは、もはやsomeobjectを参照できなくなってしまいます。

これはスコープがいつも外部に定義されたスコープにアクセスできるという事です。
→ これはスコープは、自身が定義されている外側のスコープにいつでもアクセスできるという事です。

これは上記のコードと同じような効果があります。
→ これは上記のコードと同じ振る舞いをします。

*** コンストラクタ ***

明示的にreturnステートメントがある場合、Objectの値を返すだけでなく関数はこのステートメントを返します。
→ 明示的にreturnステートメントがある場合、返り値がオブジェクトである場合に限り関数はその(return)ステートメントで明記した値を返します。

プロトタイプが新しく生成されたオブジェクトにセットされるまで、Barは絶対に新しいオブジェクトを返さないのです。
→ プロトタイプは新しく生成されたオブジェクトにセットされるけれども、Barはその新しいオブジェクトを返さないのです。

大半の場合に推奨されるのは、newの付け忘れによるバグを引き起こしやすいので使用しない事です。
→ しばしば推奨されることとして、 newの付け忘れによるバグを引き起こしやすいので newを使用しないようにするということがあります。

新しいオブジェクトを作成するためにファクトリーを使用するか、そのファクトリー内部に新しいオブジェクトを構築する必要があります。
→ 新しいオブジェクトを作成するためには、むしろファクトリーを使用し、そのファクトリーの内部で新しいオブジェクトを作成すべきだということです。

newキーワードが省略される事により、バグの可能性がもたらされますがプロトタイプを使わない確実な理由にはなりません。
→ newキーワードが省略されるとバグになってしまうかもしれませんが、それと同じくしてプロトタイプを使わないという理由には必ずしもならないです。

*** スコープと名前空間 ***

再び、varが重大な影響を持っていない、同じ効果では無いスクリプトになります。
→ 繰り返し述べると、上記（の２つのスクリプト）は全く同じ影響を持っていません。 var を使用しないことは重大な意味を持ちます。

varを使っていない事で恐怖とバグの追跡の困難さを招くことになります。
→ varを使っていない事でバグを見つけ出すことが恐ろしく困難になります。

varステートメントは希望する影響を外側のスコープに与える場合を除いては、絶対に残してはいけません。
→ 目的とする効果を外側のスコープに与えようとしない限り、varステートメントを絶対に省略してはいけません。

barの割り当ては同じ名前のグローバル変数で上書きされてしまいます。
→ barの代入は、同じ名前でグローバル変数を上書きします。

JavaScriptの巻き上げ宣言。
→ JavaScript は宣言を巻き上げます。

この言葉の意味はvarステートメントとfunction宣言が、それらの外側のスコープに移動するというものです。
→ これは varステートメントとfunction宣言がそれらを含むスコープの一番先頭に移動するということを意味します。

上記のコードは何も実行されないうちに変換されてしまいます。
→ 上記のコードは、実行を開始する前に変換されます。

ブロックスコープの欠落はループ外のvarステートメントの移動だけでなく、その本体も移動させます。これはまたifが直感的じゃない結果になってしまいます。
→ ブロックスコープの欠落は、varステートメントをループやボディ外に移動するだけではなく、ifの構成を直観的でないようにさせます。

*** 配列 ***
JavaScriptの配列もまたオブジェクトですのでfor in ループを配列の繰り返しで使用するような理由はありません
→ JavaScriptの配列もまたオブジェクトですが、その上で繰り返し処理を行うために for in ループを使用することの良い理由は一つもありません。

上記の例では一つ余分に変数がありますが、それは配列の長さを取るためのl = list.lengthの部分です。
→ 上記の例では一つ特別な仕掛けがあります。 それは配列の長さを取るためのl = list.lengthの部分です。

また、lengthプロパティは配列自身に定義されていますが、ループのそれぞれの繰り返しで探索する為のオーバーヘッドがまだあります。
→ lengthプロパティは配列自身に定義されているけれども、ループの繰り返しで毎回参照を行うというオーバヘッドが存在します。

最近のJavaScriptエンジンはこのような場合に最適化するはずです。新しいエンジンか古いエンジンで実行されるかどうかをコードが知る方法はありません。
→ 最近のJavaScriptエンジンはこのような場合に最適化するはずですが、コードが新しいエンジンで実行されるかどうかを知る手段がありません。

JavaScriptはオブジェクトの値の等価の比較方法が2種類持っています。
→ JavaScriptはオブジェクトの値の等価の比較方法を2種類持っています。

ここで一つ重要な事は、このinstanceofは異なるJavaScriptのコンテキストが起源のオブジェクト(例：ブラウザの異なるウィンドウ)では、そのコンストラクタが正確に同じオブジェクトになる訳では無いので、同じオブジェクトとして動作しないという事です。
→ ここで1つ重要なことは、異なるJavaScriptのコンテキスト(例えばウェブブラウザの異なるドキュメント）を基としたオブジェクトでは instance of はうまく動作しなません。なぜならそれらのコンストラクターは厳密に同じものではないからです。

*** コア ***
undefinedが帰される時の例をいくつか挙げます。
→undefinedが返される時の例をいくつか挙げます。

全てのundefinedが設定された値
→undefinedの値が設定された全て

→これは、setTimeoutの呼び出しにより指定された正確なディレイで実行するという確実な賭けという意味ではありません。
これは setTimeout関数の呼び出しで指定した遅延時間を正確に間違いなく得られるということでは決してありません。

さらに、文字列を関数に渡さないように推奨される理由として、それぞれのタイムアウト関数から呼び出されるという事があります。
→ タイムアウト関数によって呼び出される関数を引数に渡すために文字列を使わないということはそれ以上に推奨されています。

その上で、setIntervalの使用はそのスケジューラーがJavaScriptの実行をブロックするので避けるべきでしょう。
→さらに setInterval の使用は、スケジューラーがJavaScriptの実行によってブロックされないので避けるべきでしょう。