12/05/04 13:43:47.26
__proto__使わずに同じ事する懐かしの方法だな。
>>105はnew(C.apply(...))の形式が取りたいって最初の要件は良かったのか？
113:デフォルトの名無しさん
12/05/04 13:45:14.01
最初の要件かそもそも、不明確なので
114:デフォルトの名無しさん
12/05/04 15:36:13.38
>>112
実引数に配列を渡したいだけかと思ってたが。
115:デフォルトの名無しさん
12/05/04 15:47:45.81
>コンストラクタを呼び出すときapplyを使って引数を配列で指定したい
これが要件で
>として、とりあえず以下はダメだった。
>var o = new C.apply(null, args);
>var o = new (C.apply(null, args));
>var o = (new C).apply(null, args);
>コンスタラクタが二回呼ばれる
>oが返されない
>oがCのインスタンスにならない
これを解決したいって話だったが>>97
116:デフォルトの名無しさん
12/05/04 16:43:37.62
>>115
そうか、>>111は忘れてくれw
117:デフォルトの名無しさん
12/05/23 01:38:00.11
ECMAからES5.1仕様書のHTML版公開
URLﾘﾝｸ(ecma-international.org)
118:デフォルトの名無しさん
12/05/23 11:26:27.98
素晴らしい。
119:デフォルトの名無しさん
12/06/04 06:55:06.70
お兄ちゃん、感心しているだけじゃなくてちゃんと読まないとダメだよ？
120:デフォルトの名無しさん
12/06/04 16:23:57.05
あー毒舌な妹がこんなところにまで
121:デフォルトの名無しさん
12/06/10 04:12:22.56
なあお前ら。
関数が結合されるのがヤダヤダ！って場合は__parent__の代わりにbind使えばいいが__proto__はどうするよ？
あと自己反映のときのcalleeとか。harmonyにProxyがあるのにcalleeがダメな理由てなんだ？
122:デフォルトの名無しさん
12/06/10 11:15:47.27
>>121
__proto__のgetterはObject.getPrototypeOf、setterはObject.createである程度代用できる
arguments.calleeについてはURLﾘﾝｸ(togetter.com) が参考になる
123:デフォルトの名無しさん
12/06/11 07:47:35.23
>>122
そこ色々間違ってるから鵜呑みにしないほうがいいぞ。
124:デフォルトの名無しさん
12/06/11 10:30:16.63
>>123
どこがどう間違っているのか分からないとあなたの情報を鵜呑みに出来ない
125:デフォルトの名無しさん
12/06/11 10:30:27.73
>>123
ご指摘ありがとう
よろしければ、より参考になる資料を示して頂けると嬉しい
126:デフォルトの名無しさん
12/06/14 17:49:57.32
古い情報も相当残ってるけどwiki.ecmascript.orgが確実。
127:デフォルトの名無しさん
12/06/14 18:28:36.68
>>126
古い情報が相当残っているのに確実とする理屈がわからない
結局、どこが間違っているかも言及なしだしあてにはできないなー
128:デフォルトの名無しさん
12/06/15 08:25:24.62
書いた本人は分かってるんだろうけど書き方がイマイチだから読む人がちゃんと分からないのではってことかな？
いずれにしろ１つのサイトだけあてにするのはダメ
129:デフォルトの名無しさん
12/07/01 15:23:04.66
URLﾘﾝｸ(wiki.ecmascript.org)
>removed <| and TriangleLiterals
これだからTC-39はダメなんだ！
130:デフォルトの名無しさん
12/07/01 16:24:38.17
そらそうよｗｗｗ
これでもう復活はないなｗ 嫌いじゃないけどちょっと無理がありすぎたんだｗ
131:デフォルトの名無しさん
12/07/02 11:09:20.07
ダメなところを改善したいBrendan EichといじりたくないTC39の戦いはまだまだつづく！
132:デフォルトの名無しさん
12/07/02 13:59:41.98
AS3が一番とばっちりだよな。
先走りすぎたせいでJS2とも別モンになっちまったしhaXeの方がJS2に近いくらいだわ。
133:デフォルトの名無しさん
12/07/02 14:57:01.97
Q. JS2とは？
134:デフォルトの名無しさん
12/07/02 16:48:46.88
ActionScript3は、少し先走りすぎだったし、
Mozillaに提供した実装Tamarinのコードの質が悪く、
仕様の安易な部分と合わせて、反対派を団結させてしまったね。
結局Mozilla.orgでもTamarinを利用するTraceMonkeyプロジェクトはなくなったし。
ECMAScript 4で議論された機能については、議論継続中だからいいんだけども。
135:デフォルトの名無しさん
12/07/02 17:20:57.92
議論継続中て言ったてこれだろ？
>Tentative addition of Class Definitions Syntax and Semantics in 13.5 based upon Maximally Minimal Strawman. NOTE-Classes do not yet have full consensus within TC39 and may not survive.
11.1.5 make super references illegal in method definitions within object literals
>removed <| and TriangleLiterals
subtypingのないjs1.xにclass definition入れたってFoo.prototype={}やObject.definePropertiesの構文糖でしかないし
1.xの延長である以上型変換が暗黙の強制型変換しかないから2.0と違ってタイプルーズで真の
structural typeでないから言語仕様の問題は解決できないだろ。HarmonyやStrawmanにある型付き前提の仕様入れる気無いだろTC39。
10年無駄にして最初ゴネたimport,exportとライブラリ強化入れただけだけどその間に
本来的に必要なのはclassじゃなくてsubtypeというのを少しでも認識させたのが唯一の功績だよ。
136:デフォルトの名無しさん
12/07/06 16:22:49.91
ECMAScript 4に戻ってやり直すのが皆一番幸せになるわ
137:デフォルトの名無しさん
12/07/06 16:26:33.37
つか明らかにJavaScriptの土管化が進行中な件
ウェブのC言語と言えば聞こえはいいが、要は誰も直で書きたがらないってことだからな。
そういう用途に応えるためにLLJSとか開き直ったものも出してきてるしｗ
138:デフォルトの名無しさん
12/07/06 16:31:52.47
そして
問題点１：土管としては低効率
問題点２：土管が土管化を嫌がっていらんことするリスク
139:デフォルトの名無しさん
12/07/07 01:50:08.30
それって土管って表現するの？
140:デフォルトの名無しさん
12/07/07 09:45:23.03
6の仕様を見ていると結構いい感じだな。早いとこ普及してほしいよ。一応仕様のリリースは来年らしいけど。
141:デフォルトの名無しさん
12/09/10 09:02:29.57
>JavaScriptの土管化
>JavaScriptの土管化
>JavaScriptの土管化
>JavaScriptの土管化
>JavaScriptの土管化
>JavaScriptの土管化
>JavaScriptの土管化
>JavaScriptの土管化
>JavaScriptの土管化
142:デフォルトの名無しさん
12/09/27 00:40:57.35
ECMAScript6にいつのまにかclassが追加されててﾜﾛﾀw
どうやら6/15のDraftに追加されたようだ。
さがしたら>>135で話題になってたけど、言ってる意味がわからん。。
ちょっと勉強するか。
143:デフォルトの名無しさん
12/09/27 01:36:15.53
しかし仕様書を見てもよくわからんな。。
もう少し土管化するまで待つか
144:デフォルトの名無しさん
12/09/27 08:05:08.60
土管化が何を指してるのかさっぱりだ
145:デフォルトの名無しさん
12/10/01 02:35:37.39
URLﾘﾝｸ(www.slideshare.net)
URLﾘﾝｸ(constellation.github.com)
この辺りを見てclassについてある程度理解出来た。
単なるシンタックスシュガーなんだな。それで十分だ。
それにしても、モジュールの機能が無いみたいだけどそれ以外は普通にモダンな
スクリプト言語になっちゃうね。
146:デフォルトの名無しさん
12/10/01 12:03:59.01
言語設計は最初からモダンだけどな。
ライブラリ設計は古かったけど。(殆ど無いに等しいし)
147:デフォルトの名無しさん
12/10/14 16:38:50.03
ECMAScriptの最新 ＝ TypeScriptなの？
148:デフォルトの名無しさん
12/10/15 00:05:30.16
私も興味があります
現在策定中のECMAScriptとTypeScriptの相違はどの程度なのでしょうか？
149:デフォルトの名無しさん
12/10/15 00:19:27.67
マージされることがあるとしても、バージョン二つくらい後だろ。
クラス仕様については、ECMAScriptとほぼ同じ機能になってるな。
違いは組み込みかライブラリ化の違いくらい。
150:デフォルトの名無しさん
12/10/15 17:18:28.74
>>149
ありがとうございます
そうなると、あと10年位掛かりそうな・・・
オプショナルな静的型付けとかジェネリックとか、次の仕様に取り込まれないかな
151:デフォルトの名無しさん
12/10/15 17:47:41.70
ECMAScript4の失敗を忘れたのか？
そこまでやるならいっそ新しい言語にしてくれたほうがマシ
糞みたいな互換性やら名前やらとはさっさとおさらばしたいぜ
152:デフォルトの名無しさん
12/10/15 20:19:01.64
ECMAScript4の失敗についてはよく知らないけど
TypeScriptはJavaScriptの上位互換だよ
TypeScriptのように、既存のJavaScriptが動くように仕様を拡張したら問題ないのでは？
153:デフォルトの名無しさん
12/10/15 20:43:43.76
ECMAScript4の失敗
URLﾘﾝｸ(ja.wikipedia.org)
URLﾘﾝｸ(developers.slashdot.jp)
URLﾘﾝｸ(news.mynavi.jp)
154:デフォルトの名無しさん
12/10/15 22:08:55.95
>>153の記事を読んでの感想。
ECMAScript 4の失敗というのは、ECMAScript 4の仕様自体の問題というよりも、
Adobe、Mozilla、Opera、Google陣営と、Microsoft、Yahoo!陣営による政治的な問題
という色彩が強いように感じた。
例えば、ECMAScript 4が決裂した2008年当時は、Microsoftは「Web標準」を軽視し、
Silverlightを普及させようとしていたのではなかったか。
つまり、当時のMicrosoftは、Silverlightを普及させるために、JavaScriptが高機能になるのを嫌った。
一方、JavaScriptの重要性を認識していたMozillaやGoogleなどは、JavaScriptを大幅に拡張したかった。
そうした各陣営の様々な政治的な思惑があって、ECMAScript 4は決裂したように思う。
しかし、今は、Microsoftも「Web標準」にシフトして、業界全体でJavaScriptの重要性に対する認識が
共有されるようになったのではないか。
Webサイトに限らず、デスクトップアプリケーションやモバイルアプリ、サーバーサイドにまで
JavaScriptが使われている。
そうした中で、JavaScriptによる開発が行いやすいよう、ECMAScript 4のような大規模な拡張が
JavaScriptには求められているし、こうした要求に異を唱える陣営は今はもういないのではないか。
だから、合意に達するのであれば、慎重かつ大胆にECMAScript 6の仕様を拡張してほしいというのが、私の考え。
155:デフォルトの名無しさん
12/10/15 22:58:57.10
MicrosoftはMicrosoftで思惑あったと思うが、
・AdobeがActionScriptをECMAScript4にしようとしていた。
・既に広く広まったECMAScript3との互換性の問題が軽視。
古いコードをどうやって実行するのか議論が深まらないまま。
・ECMAScript4の新機能の多くがActionScriptをコピーしただけで、
入れることの是非、設計詳細部の議論が深まらないまま。
・ActionScriptの機能の多くが実装者の思いつきで設計。(Adobeの公開MLに残ってる)
・参照実装であるtamarinのコードの質の低さ。
というわけでストップになった。
ただしECMAScript4で導入されそうになった機能は捨てられたわけでなく、
多くは議論を深めてから入れる方向で考えられている。
Webの現状を考えると時間をかけるのが妥当と判断された。
それはBrandenの声明にもはっきり書かれている。
156:デフォルトの名無しさん
12/10/15 23:48:22.01
>>155
ActionScriptはECMAScript 4を元に作られたと思っていたのですが、
実際は逆で、ActionScriptを元にECMAScript 4の仕様を決めようとしていたということでしょうか？
ECMAScript 4は2回決裂しているようなので、そこらへんの前後関係は良く分かりませんが、
少なくとも2回目の決裂に関しては、Adobeの強引さとActionScriptの出来が問題になったということですかね。
ECMAScript 6に関してはしっかり議論して合意に達してほしいですね。
便利な機能が入ることを期待しつつ、時間が掛かることをもどかしく思ったりしつつ、
末端プログラマとして、仕様策定者に期待したいです。
157:デフォルトの名無しさん
12/10/16 08:10:49.32
>実際は逆で、ActionScriptを元にECMAScript 4の仕様を決めようとしていたということでしょうか？
ドラフトを先走って実装しただけ
158:デフォルトの名無しさん
12/10/18 19:10:41.39
>>154
前半の陰謀論はまったく要らないな
159:デフォルトの名無しさん
12/10/19 21:05:59.32
JavaScriptの未来？
URLﾘﾝｸ(brendaneich.github.com)
160:デフォルトの名無しさん
12/10/19 21:13:28.34
>>159
ちなみにBrendan Eichのスライド
161:デフォルトの名無しさん
12/10/19 21:25:10.17
Brendan Eich @BrazilJS 2012 - The State of JavaScript
URLﾘﾝｸ(www.youtube.com)
162:デフォルトの名無しさん
12/10/20 00:54:46.78
typescript出たばかりなのに、No Classかよw