アカウント名:
パスワード:
しかし、名前空間とパッケージは3.1に含まれないのか。
名前空間もパッケージも、 3.1 に取り込まれないだけでなく、 ECMAScript Harmony プロジェクトにおいては二度と考慮しないようです。逆に言えば、これらを Ecma Technical Committee 39 で議論することがあるとすれば Harmony プロジェクトが終わった後ということでしょう。
Brendan Eich さんのメールから引用 (強調は引用者):
Executive Summary [...]3. Some ES4 proposals have been deemed unsound for the Web, and are off the table for good: packages, namespaces and early binding. This conclusion is key to Harmony.
Executive Summary [...]
3. Some ES4 proposals have been deemed unsound for the Web, and are off the table for good: packages, namespaces and early binding. This conclusion is key to Harmony.
試訳:
ところで 「すっきりした(desugar)」 という言い回しが散見しますが、 これは「構文糖(Syntax Sugar)」などで使うニュアンスにおける「sugar」なのでしょうかね?
おっしゃる通りこの sugar は syntax sugar の sugar です。今の文章の場合、 desugar は糖衣構文を展開して糖衣構文を使わないコードに直すことなので、「すっきりした姿になる」は誤訳だと思います。クラス等の言語機能が糖衣構文で実現できれば言語仕様や実装がすっきりするのは事実でしょうけれど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
Harmony (スコア:5, 参考になる)
JavaScript 2.0はECMAScript 3.1ベースに、ECMAScript 4は譲歩 [mycom.co.jp]
Re: (スコア:1, 興味深い)
しかし、名前空間とパッケージは3.1に含まれないのか。
一番わけがわからないところだから、ぜひ取り込んで欲しいんだけどなあ。
パッケージ等 (Re:Harmony) (スコア:4, 参考になる)
名前空間もパッケージも、 3.1 に取り込まれないだけでなく、 ECMAScript Harmony プロジェクトにおいては二度と考慮しないようです。逆に言えば、これらを Ecma Technical Committee 39 で議論することがあるとすれば Harmony プロジェクトが終わった後ということでしょう。
Brendan Eich さんのメールから引用 (強調は引用者):
試訳:
Re: (スコア:2, 興味深い)
早期束縛は、Javaみたいな強い型付けの言語への方向性だから、SCRIPT言語としてそれをやめるってのはまあ1つの考え方だなあとは思うんだけど、
パッケージと名前空間(似たようなもんだと思うぞ)が「Webでの利用において不適切」と判断されるというのは、どういう理由なのか、誰か説明してください。
ぜんぶObject(辞書)を適宜入れ子にしちゃればいいじゃん、という主張なんでしょうか?
だとすれば「いいじゃん」そのものについては納得できなくもないんですが、
ただ「Webに合わない」って
Re: (スコア:1, 参考になる)
まず
「ES4 における名前空間のユースケースのひとつは, (名前空間の intrinsic による)アーリーバインディングと, 性能の向上, プログラマの理解しやすさの改善でした」
という指摘が有るので、
やっぱり名前空間→早期束縛っていう流れは有るようです。
そして
「しかしウェブのようにコードを動的にロードする場面では, アーリーバインディングとレイトバインディングの衝突を避ける優先順位づけや予約の仕組みは必要です.」
と続いているので、もろに「動的ロードと相性が悪い」「というかそういうアーキテクチャの名前空間を想定している」系の話題のようです。
Re:パッケージ等 (Re:Harmony) (スコア:2, 参考になる)
おっしゃる通りこの sugar は syntax sugar の sugar です。今の文章の場合、 desugar は糖衣構文を展開して糖衣構文を使わないコードに直すことなので、「すっきりした姿になる」は誤訳だと思います。クラス等の言語機能が糖衣構文で実現できれば言語仕様や実装がすっきりするのは事実でしょうけれど。