- ECMAScript デス 4
779 ：デフォルトの名無しさん[sage]：2015/07/26(日) 22:37:35.22 ID:CUGdI6EM - >>767
> あくまでプロトタイプベースの糖衣構文として組み立てていく道以外は難しい
> 今のMapの仕様はES5でも簡単に再現可で、仕様から実装も透けて見えJSerには自然に受け入れられる
多分ここら辺の感覚が違うんだ。
俺は、ES5でエミュレーションできるのならMap.jsとして提供すべきで、仕様を追加する必要はないと考える。
ただ、jQuery等も含め「今既にあるもの」から仕様を取り込んできたJSとしては、そちらの言う感覚の方が自然で、
Map.jsを本体に取り込んだということなのだろう。
たぶんJSは仕様の意味が軽い。そして本質的な改訂が為されていない。
C#は3.0でLINQとラムダ(クロージャ）を導入した。本当に言語側からのサポートが必要なら、やるしかない。
(ただしC#は完全上位互換、つまり過去のコードはこれでもそのまま通った)
クラスが欲しいけど言語側からのサポートがないから永遠とクラスモドキ、というのは全くの無駄だ。
要るのなら導入すべきで、要らないのならすっぱりあきらめるべきだ。(個人的にはプロトタイプで問題ない)
必要なのはクラス構文そのものではなく、動的保護なのだろうし。
|
- ECMAScript デス 4
780 ：デフォルトの名無しさん[sage]：2015/07/26(日) 22:38:24.89 ID:CUGdI6EM - 仕様の改訂は当たり前だが最小限に済ませるべきだ。そして整合性は最大限に保たないといけない。
Mapの導入経緯は、「objをキーに出来ない」であり、元々Objectのパッチだ。
そしてさらにそれ用の仕様、Symbol.xxxってのは、パッチのパッチになる。（ただし列挙体の導入はいずれ必要だが）
これをやりだすとゴミ仕様が膨らんでゴミ言語になっていく。
元々の問題点、「objをキーに出来ない」を直接解決するのが正しいやり方だ。
そもそもキーのtoString()仕様は捨ててもいい類のものだ。実際 [Object Object] であり、使い物にならなかった。
だからパッチ当てで後方互換を確保しておけばそれで十分だ。(今後ともパッチのパッチが必要とはならない）
新しくJSを使う人にとっては、Map[]で何の問題も感じない。最初からそうあるべきだった。
オブジェクトリテラルの書き方についても、最初からJSONと同じでよかった。（キーがStringであることを明示）
元々の仕様に不備があったからおかしなことになっていたので、それを訂正するということ。
結果、矛盾は解消、仕様は小さくなる方向だ。
【ES6仕様】
Objキーは常にtoString()
MapキーはtoStirng()なし、ただし[]アクセスできず
Symbol.xxxを導入
【Objキーは生仕様】
Objキーは生で使う、よってMapは不要
(後方互換性のためにパッチを用意する)
|
- ECMAScript デス 4
781 ：デフォルトの名無しさん[sage]：2015/07/26(日) 22:39:02.52 ID:CUGdI6EM - 仕様もプログラムと同じで、新機能が欲しいときに、パッチを当てるか、思い切って書き直すかを選択しないといけない。
ただ、言語仕様についてはもっと原理的で、パッチすら当てないほうがいい。
今のJSの仕様だと確実に迷走する。この先JSは死ぬことになるだろう。
集団指導体制なのかは知らないが、その悪い点が出ている。無難な選択しか出来ず、決めきれていない。
この先、新しいプログラミングパラダイムが出現したとき、取り込むという決断を出来ずに死ぬ。（今のJava）
JSの優位点はJSそのものではなく、ブラウザで動く点だ。だから、逆に言えば、ブラウザに他言語が搭載されれば廃れる。
Dartはこれを目指して失敗した。後はTypeScriptだが、あれは置換は狙っていないようだ。
クライアントサイドはしばらく揺ぎ無いだろうが、サーバサイドは自前で決められるので、乗り換えはしやすい。
サーバサイドで実績を積んだ言語が載り換わってくることになるだろう。
|
- ECMAScript デス 4
782 ：デフォルトの名無しさん[sage]：2015/07/26(日) 22:40:01.24 ID:CUGdI6EM - >>767
> そしてAbstractReferences自体が弱参照とかそういう話ではない
ああ、これは理解している。
> 但し、順番が逆なことでいろいろと都合もいいという話
一応半分以上読んでみたが、やはりよく分からない。
x@r=y自体に使い道があるのならいいが、r[x]とx@rの違いでフックしたいだけなら、ただのゴミだ。
ライフタイムがx>rのときにフィットするというのは確かにそうだが、
それはHaskellの遅延評価みたいに全面的にx@rしか許さない状況で試してみないと分からない。
APIを全部見せたくないというのは、
publicが上書き放題な今のクラスモドキをクラス（動的保護つき）にすればいいだけだ。
俺はクラスを多用していないのでbindのありがたみはあまり分からないが、
内部から呼ぶときにはthisが変わってウザいのは確かだ。
とはいえ、::は他言語だと単にクラス階層という印象があるが、bindまで絡めると余計に分かりにくくならないか？
あと、PrivateFieldsとAbstructReferenceは直接関連はなさそうに見えるが、、、
|