08/05/08 06:15:58
es3のほうが言語として美しい。es4はキメラ化した愚作。
251:デフォルトの名無しさん
08/05/08 17:37:52
確かに言語としてはes3の方が美しいよな。
クラスベースにしたのにプロトタイプのこすとかイラネ。
まあIEがまともに実装することは永久にないのでwebでは日の目見ないだろうな。
標準クラスライブラリが多すぎるのも問題だ。
252:デフォルトの名無しさん
08/05/08 18:12:50
とはいえprototype.jsとか使って疑似クラスとか定義しているのが主流なのを見ると、
言語の機能としてクラスベースを取り入れるのも正しい方向性っちゃそうなのかもしれない。
既存のクラスをprototypeで拡張できなくなるのはちょっと寂しいけどな。
253:デフォルトの名無しさん
08/05/08 18:25:13
prototype.jsって別にいらないと思うんだがそんなにプロトタイプベースは嫌いかね？
254:デフォルトの名無しさん
08/05/08 18:39:39
今のところ既存のクラスをprototypeで拡張出来るはずだが。
es4 は今がりがり仕様を削ってるところなので様子見。
es3.1 がちっとづつ進んでて興味深い(MS主導)
255:デフォルトの名無しさん
08/05/08 20:23:02
>>253
俺もprototype.jsは嫌い。
つーか、マトモな感覚してたらあんなwarning出まくりのライブラリなんて気味悪くて使えん。
256:デフォルトの名無しさん
08/05/09 01:10:40
そのマトモな感覚ってのがecmaの仕様理解しててプロトタイプベースも使いこなしてるって事だから
実際にajaxアプリ書いてる連中には居ないだろうな。
257:デフォルトの名無しさん
08/05/11 04:26:31
このスレ見て俺ってまだ勉強不足なんだなって思ったよ
ああ・・・
258:デフォルトの名無しさん
08/05/13 13:49:16
似非クラスベースやりたいだけならprototype.jsなしでも
継承モデルとか作れなくもないしな
カプセル化の面で多少悩みは残るけど
でもjQueryは手放せない
259:デフォルトの名無しさん
08/05/13 13:56:49
継承させる場合はFunction.apply()使えば良いけどミックスインしか出来ないんだよな。
260:デフォルトの名無しさん
08/05/14 09:11:18
Yahoo UIってどうよ
めちゃくちゃメソッド・プロパティあるけど
261:デフォルトの名無しさん
08/05/14 11:57:47
ecma-262関係ないな。
262:デフォルトの名無しさん
08/06/19 16:14:32
fx3がリリースされてjs1.8が登場したわけだが・・・rhinoはまだか！？
263:デフォルトの名無しさん
08/06/19 20:20:40
1.8以前に1.7R2がまだ…
URLﾘﾝｸ(blog.norrisboyd.com)
264:デフォルトの名無しさん
08/06/19 22:08:11
SpiderMonkey の 1.8 が出てからじゃない？そうでないと仕様確定できないとか？
Fx 3.0.* が結構出てからでしょ。
URLﾘﾝｸ(developer.mozilla.org)
もまだいまいち、JSON, Slice Syntax は js には入ってないし、
URLﾘﾝｸ(bugzilla.mozilla.org)
が入ってない。
265:sage
08/06/29 22:55:41
tamarin付属のescにて、
es> eval("2/1");
SyntaxError: (EVAL CODE): Binding form not legal: {/*NamespaceFixture*/ 'ns': {/*InternalNamespace*/ 'name': '<#internal (EVAL CODE)>'}}
となるのはなぜですか?
266:デフォルトの名無しさん
08/06/29 23:43:48
まだ文法パースすら出来てないんじゃない？
RIもそんな感じだし。
267:デフォルトの名無しさん
08/06/30 00:03:49
文法ころころ細かく変わってるからおかしくなるのは仕方ないんだけど、
数値まわりは lexer がおかしいのかも。
RI-M2 で function test2d {...} とやったらエラー出たのはびっくりした。
(2d で数値リテラルと解釈したらしい、なんじゃそら)
268:デフォルトの名無しさん
08/06/30 15:03:08
>>267
function test2d() { ... }
じゃないんですか。
269:デフォルトの名無しさん
08/06/30 17:32:35
>>268
typo った。スマン
270:デフォルトの名無しさん
08/07/06 23:17:16
無名関数を #(x,y)と書く処理系があったのですが、他でも同じように書いて動くのでしょうか？
271:デフォルトの名無しさん
08/07/06 23:24:58
初めて聞いたkwsk
272:デフォルトの名無しさん
08/07/07 13:13:42
右シフト演算子、「符号ありが >> で、符号なしが >>>」に
決めたのはなぜだろう。
「符号なしが >> で、符号の分を更にシフトする方が >>>」って考えると
しっくり行くのに。っつーかそう誤解してた。
更に、逆に解説してるサイトもある。
273:デフォルトの名無しさん
08/07/07 13:56:35
>>272
符号の分をさらにシフトすると何がうれしいんだい？
274:デフォルトの名無しさん
08/07/07 14:13:07
>>273
質問の意図がよく判らないけど、
負の数を負のまま扱えるから嬉しい。
算術シフトの名の通り。
275:デフォルトの名無しさん
08/07/07 14:25:28
>>274
負の数のまま扱いたければ、普通に算術シフトを使う処理系で>>すればいいだけ。
何かカンチガイしてないか？
276:デフォルトの名無しさん
08/07/07 15:20:24
よく判らんなー。
元々は>>272の「>>と>>>を誤解してる人がいる」って話なのに、
>>273が「何がうれしい」と謎の質問をしてるのが、こじれの発端だ。
嬉しい/嬉しくないっていう評価軸の話は元の質問には無関係。
>>275も何か変な事を言ってる。
算術右シフトも論理右シフトも、ECMAScriptの話であって、
「そういう処理系で」って話は、どう飛躍してるんだ。
277:272
08/07/07 15:26:46
何か話がややこしく(?)なった様で申し訳ない。
>>273
ビット操作物を書いてる時に、論理シフトを期待して>>を使ったら
MSB=1の時に意図しない動作をしたのが発見の経緯だったので、
「符号をシフトされて（私個人が）嬉しくなかった」という話。
で、>>と>>>を今の様に割り振った理由を知りたいな、と。
278:デフォルトの名無しさん
08/07/07 15:58:02
別に理由なんかないと思うがな。最初にそう決めたからそうなんだろう。
数学で足し算の記号に「+」を割り振ったのはなぜか？
とかいわれてもそう定義したからとしか言いようがなくね？
279:デフォルトの名無しさん
08/07/07 16:46:53
単に慣例に従っただけってのが大きいと思うよ URLﾘﾝｸ(d.hatena.ne.jp)
280:デフォルトの名無しさん
08/07/07 17:43:26
前例があるんじゃ、そりゃ従うわ。
でも>>272の
＞「符号なしが >> で、符号の分を更にシフトする方が >>>」って考えると
＞しっくり行くのに。
はよく判る。
で、>>273は何を訊きたかったんだろう？
281:デフォルトの名無しさん
08/07/07 17:46:03
単に茶々入れたかっただけだと思うけどな
282:デフォルトの名無しさん
08/07/07 18:01:01
Number型は符号付きだから、
>>が算術シフトで、>>>が論理シフトである方が自然。
C言語でのsigned int + >>の多くの実装(ただし仕様的には未定義動作)と合致してる。
283:デフォルトの名無しさん
08/07/07 18:38:19
たぶんECMAScriptが慣例にあわせてるってのはわかってて聞いてるんだと思うんだけど…
数値型に対する演算子なんだから算術シフトの方が自然な動作で
論理シフトの方が例外的な振る舞いだよな…
「符号の分を更に…」って感覚はちょっとわからないな…
シフトしてるビット数は算術のほうが少ないわけだし
284:283
08/07/07 19:18:50
なんか違うなｗ
シフトしてるビット数は同じで、「最上位ビットを０にする」っていう処理が
追加されたのが論理シフトなんだから「符号の分を更に…」って感覚は
よくわからんと言いたかった。
285:デフォルトの名無しさん
08/07/07 19:33:44
>>280
いや、MSBを保存することを「更にシフトする」という言い方では普通は理解不能だろ。
俺もわからんかった。普通の算術シフトの後にもう1回シフトするのかと思ったよ。
286:デフォルトの名無しさん
08/07/07 19:50:15
>>284
わざわざ「最上位ビットを０にする」って訳じゃない。
左シフトだって、別に最下位ビットを０に「する」んじゃない。
アセンブラ経験者だと判ってくれるかな。
シフトは、左、右、算術右で、
論理型がデフォ、算術は敢えて明示するみたいな。
287:デフォルトの名無しさん
08/07/08 00:07:50
間違った自分はバカじゃないと同意してほしいわけですね、わかります。
288:デフォルトの名無しさん
08/07/08 03:22:22
結局、なんで「さらにシフトする」なんて言ったのか、ワケワカランと思うのは俺だけか？
自称よくわかった人が複数いるみたいだからw、教えてよ。
算術シフトのどこがどう「さらにシフトする」ことになるのか。
289:デフォルトの名無しさん
08/07/08 08:10:19
「更にシフト」じゃなく、「更にひと手間」だな。
290:デフォルトの名無しさん
08/07/08 09:07:18
更にひと手間つーか、MSBをイジらないだけじゃん。全然手間じゃないよ。
291:デフォルトの名無しさん
08/07/08 10:17:28
元の奴の感覚は判るが、言葉が悪い。
動作で<<と（空き位置に０が入るという）対称性があるのは>>>だが、
見た目の対称性は<<と>>だから、違和感がある。
と書けばよかった。
292:デフォルトの名無しさん
08/07/08 10:17:37
符号「拡張」っていうくらいで、
nビット(n>1)シフトする時は、
上位nビットに補填するけどな。
(いまどき1ビットづつシフトしない)
293:デフォルトの名無しさん
08/07/08 10:20:01
>>291
無理やり論理演算の視点になってるよ。
*2, /2だという算術演算の視点なら逆だ。
プログラマは暗黙の仮定に拘泥してはならない。
294:デフォルトの名無しさん
08/07/08 13:46:11
>>293
無理やりも何も、シフトは論理演算でしょ。
295:デフォルトの名無しさん
08/07/08 13:54:51
シフトはビット演算です。
11.7 Bitwise Shift Operators
11.7.1 The Left Shift Operator(<<)
>>は符号付き算術演算です。
11.7.2 The Signed Right Shift Operator(>>)
>>も符号なし算術演算です。
11.7.3 The Unsigned Right Shift Operator(>>>)
296:デフォルトの名無しさん
08/07/08 14:02:04
>>293
なまじ*2、/2の代用になってるからなー。
っつーか、この発想こそアセンブラだ。
なのにアセンブラ的発想は少数派になってる不思議。
297:デフォルトの名無しさん
08/07/08 14:22:08
C/C++みたいにbit長も内部表現も仮定しない仕様を持つ言語の「仕様を」知っ
ている人と、Java,Javascriptのようにbit長規定、内部表現も暗に仮定し
ている言語しか知らない人では、かなり温度差があるんじゃないでしょうかね。
前者は、言語習得時に仕様を確認する習慣があると思います。仕様を確かめな
い感覚派は、アセンブラ知っていればこう考えるはずと、自分の感覚に陥って
しまうんじゃないでしょうか。
298:デフォルトの名無しさん
08/07/08 15:15:53
ビット演算で32ビットに丸められるのは、レジスタ幅等の効率の面から判るんだけど、
整数リテラルの±2^53って、どういう根拠なんだろう。
IEEE754の64ビット表現だと、仮数部は52ビットだし。
299:デフォルトの名無しさん
08/07/08 16:08:22
仮数部52ビットの上に、見えない1が立ってるからでは？
300:デフォルトの名無しさん
08/07/08 16:32:06
本当にアセンブリ言語を知ってる人ならば符号付き演算と符号無し演算に最低限の注意は向けるはずです。
変な思い込みで符号に注意を向けない人は、生兵法でアセンブリを使っている人でしょう。
301:デフォルトの名無しさん
08/07/08 17:15:40
>>299
あーそっか。俺バカ。
302:デフォルトの名無しさん
08/07/08 17:16:55
>>300
最初のネタに戻ると、間違えて逆に解説してる本やサイトがある。
303:デフォルトの名無しさん
08/07/08 22:35:02
そりゃ注意はしてても、まさか演算子の動作を逆に解説してるとは思わないよな。
複雑な関数やバグの確認ならともかく、演算子を事前にテストしてから使う様な事はしないし。
304:デフォルトの名無しさん
08/07/08 23:38:29
Webのクソみたいな解説サイトとかあてにしてたらダメだろ
書籍で間違った解説してるものがあるなら被害者を減らすためにも書名を晒すべき
305:デフォルトの名無しさん
08/07/08 23:45:52
今なら乗除はコンパイラ任せの*/で良いね。シフトはunsignedだけで良いんじゃね？
306:デフォルトの名無しさん
08/07/08 23:49:18
コンパイラの意義は抽象化にあるんだから、
シフトはビット操作にだけ使うべきでしょ。
符号の有無じゃなく。
307:デフォルトの名無しさん
08/07/08 23:58:03
My UNIX Series 『入門 JavaScript』、久野靖、アスキー
P.43
■２項演算子
～（中略）～
●<<、>>、>>>
左シフト、右シフト、算術右シフト。
奥付では初版。
以降の版で直ってるかは不明。
308:デフォルトの名無しさん
08/07/09 00:27:41
まさかだけど、==と===みたいに
途中で意味が入れ替わった訳じゃないよね？
309:デフォルトの名無しさん
08/07/09 09:58:00
あれは痛かったなｗ
310:デフォルトの名無しさん
08/07/09 10:27:43
>>308
revision 1の仕様書を読んだが、
The left shift operator ( << )
The signe3d right shift operator( >> )
The unsigned right shift operator( >>> )
というわけで、変わってはいないようだな。
久野さんにしては珍しいチョンボだね。
311:デフォルトの名無しさん
08/07/09 12:04:33
久野さんって、fjでお馴染みの、
高校の情報の教科書を書いてたりする人？
312:デフォルトの名無しさん
08/07/09 13:15:28
fjﾅﾂｶｼｽw
313:デフォルトの名無しさん
08/07/10 18:53:58
ES4では、byte型、int型, uint型が増えますが、
shift演算子の意味はES3のままのようですね。
少なくともtamarinでは、今のところそう実装されています。
314:デフォルトの名無しさん
08/07/10 19:25:44
だからなに？
315:デフォルトの名無しさん
08/07/10 19:46:11
つ お知らせ
316:デフォルトの名無しさん
08/07/10 23:54:34
random seed ってないのね。
まったく同じ乱数列をもう一度再現したいんだけど、
自前でそういう乱数を持つしかないか。
そういや、seed を２回設定すると
副作用で時刻が得られる言語があったよね。
317:デフォルトの名無しさん
08/07/11 00:48:57
>>313
> ES4では、byte型、int型, uint型が増えますが、
byte 型は×
URLﾘﾝｸ(bugs.ecmascript.org)
URLﾘﾝｸ(mail.mozilla.org)
int, uint 型も多分×
URLﾘﾝｸ(bugs.ecmascript.org)
AS(Tamarin) は独自拡張として残すんだろう、多分。
318:デフォルトの名無しさん
08/07/11 10:01:48
tamarinは、ES4モードじゃなくてASモードの時だけ
既存のint, uintを有効にするんじゃないかな。
ES4のint, uint除外は最近のことなので、
// lib-march-2008に関連ドキュメントも至急削除のコメント
tamarinはまだ追いついてないと思う。
319:デフォルトの名無しさん
08/07/11 10:20:45
>>316
awkだ。
srandすると、現在時刻がseedになる。
もう一度srandすると、前のseedを返す。
320:デフォルトの名無しさん
08/07/11 12:37:48
仕様変更しすぎだな
321:デフォルトの名無しさん
08/07/12 00:01:36
Number型、桁あふれで内部で勝手にfloat, doubleに昇格されると、
疑似乱数生成のアルゴリズム実装に神経使うよなあ。
322:デフォルトの名無しさん
08/07/17 03:24:05
var a() = function
{
this.b = function() {}
}
を、prototypeを使って書き直す場合、どうやって書けば良いのでしょうか？
323:デフォルトの名無しさん
08/07/17 03:29:37
なんだそりゃ
var a = function() { };
a.prototype = {
b: function() { }
};
324:デフォルトの名無しさん
08/07/17 14:29:38
>>322
一応言っとくが>>322と>>323のコードは等価じゃないぞ。
325:デフォルトの名無しさん
08/07/17 18:07:23
誰が等価なコードを望んだんだろう
326:デフォルトの名無しさん
08/07/18 05:17:50
aを実行しちゃっててわろた
327:デフォルトの名無しさん
08/07/29 14:56:37
var o = new Object();
o.f = function() {
return; // 内容は何でもいい
} // ←ここにセミコロン
(function() {
void 0; // 内容は何でもいい
})();
このままだとエラーで、o.f に代入する関数リテラルの最後にセミコロンを付けると問題ない。
ここは暗黙で文の区切りにならない？
328:デフォルトの名無しさん
08/07/29 16:47:10
ならないからエラーになるんじゃないかな。
とりあえず{}かfuncton() {...}に対する関数呼び出しとして扱われてるはず
329:デフォルトの名無しさん
08/07/29 19:35:26
暗黙な 文の区切りなんて obsolete ね いつか動かないはずのコード
330:デフォルトの名無しさん
08/07/30 01:43:38
というか仕様書読み直して来い
どの識別子が終端文字とみなされるか調べて来い
331:デフォルトの名無しさん
08/08/04 16:05:45
>>321
uintは欲しかったな。
ハッシュ計算、疑似乱数、ビット演算用に。
ブラウザ専用言語だと需要が少ないところだろうが。
332:デフォルトの名無しさん
08/08/04 23:46:54
es4は組み込み言語としての汎用性を求めてなかったっけ？
333:デフォルトの名無しさん
08/08/05 00:46:57
331だが、ちょっと調べてみると、
JITで型推論するからNumberあれば十分という戦略らしい。
少なくともtamarinはその方向みたいだ。
そりゃmodulo演算してれば、整数型なことが分かるけどなあ…
334:デフォルトの名無しさん
08/08/05 04:35:05
>>333
え、型推論をコンパイル時ではなくJITでやるのか・・・ある意味すげーな、それ。
一般の型推論は理論上NP完全だぞ。実際にはそこまで最悪なケースは滅多にないけど。
335:デフォルトの名無しさん
08/08/05 21:42:36
>一般の型推論は理論上NP完全
VMが型推論のパターンを学習すればいいんだ！
336:デフォルトの名無しさん
08/08/05 22:24:16
「できる」と「簡単にできる」は別物だろ
自分とこの処理系ならできるからいいって言われても…
337:デフォルトの名無しさん
08/08/17 08:30:22
URLﾘﾝｸ(tech.slashdot.org)
URLﾘﾝｸ(mail.mozilla.org)
338:デフォルトの名無しさん
08/08/19 09:42:55
ECMAScriptHarmony - ECMAScript Harmony
URLﾘﾝｸ(www.hyuki.com)
339:デフォルトの名無しさん
08/08/19 11:56:26
ES4あぼん、か。
340:デフォルトの名無しさん
08/08/19 12:27:53
>>339
packageがなくなるのも確定か…
packageだけは欲しかったのに
early binding, namespaceがなくなるのはいいんだが
341:デフォルトの名無しさん
08/08/19 23:55:05
ES ed.4がなくなってES ed.3.1を作るってこと？
まあ無難だがモジュール性の確保がなぁ。
342:デフォルトの名無しさん
08/08/19 23:59:08
プロトタイプベースOOP派の勝利だな。
343:デフォルトの名無しさん
08/08/20 02:37:40
>>341
4はなくなるわけじゃない。将来の候補の一つ。
大きく変える前に3.1を出して様子見。
MicrosoftとしてはActionscript牽制に成功。
344:デフォルトの名無しさん
08/08/20 02:50:29
>>342
それはまだこれからの協議。
package, early binding, namespaceがなくなること決定らしいが、
これは全く意味が分からない。
言語的にライブラリ管理補佐機構が大きく後退。
Ajaxに暗雲垂れ込める感じ。
345:デフォルトの名無しさん
08/08/20 15:46:07
early binding はコンパイル時エラー検出や、class や namespace を
コンパイル時(静的)に決定することで速度改善と実行時書き換えによる
セキュリティエラーを防ぐ、ということだったんだが複雑化と実行時定義との
衝突がうまく解決できないということで OUT
package は namespace の構文糖、４月の段階で既に OUT だった。
namespace は識別子の拡張だったんだが、early binding 抜きだと
速度が落ちまくる。
ライブラリ機構は ES-ML ではいまのところ、Scheme の RSR5 というか、
Perl 類似のものを Dojo で採用されているような構文で検討中。
個人的には catchall が何とかなって欲しいんだが、namespace 抜きだと面倒そうなんだよなぁ
346:345
08/08/20 18:23:47
> Dojo で採用されているような構文で検討中。
間違えた、ES-ML で出てるのは Helma NG と Caja だった。
URLﾘﾝｸ(dev.helma.org)
URLﾘﾝｸ(google-caja.googlecode.com)
まぁ議論のベースになってるのはこれ。
URLﾘﾝｸ(wiki.ecmascript.org)
347:デフォルトの名無しさん
08/08/23 23:22:37
es4にはwktkがない！何故だ！？
348:デフォルトの名無しさん
08/08/24 11:38:18
公式に終わってんだからあっても困る、ES3.1 は？
349:デフォルトの名無しさん
08/08/24 12:19:00
型指定変数宣言
var hoge:Number;
も無くなったの？
350:デフォルトの名無しさん
08/08/24 14:12:33
それは困るなぁ
351:デフォルトの名無しさん
08/08/24 16:57:42
型周りは一からやりなおし。どうなるかわからんが素案には
URLﾘﾝｸ(wiki.ecmascript.org)
> A type annotation has the syntax " : type-expression ".
とあるがな。
352:デフォルトの名無しさん
08/08/25 19:37:51
ECMAScript デス 3
が
らぶ デス 3に見えたメガネ買い替えてくる・・・。
353:デフォルトの名無しさん
08/08/25 20:01:58
メガネより変えるべきものがあるだろ
354:デフォルトの名無しさん
08/08/25 20:57:29
>>353
替えの入手先の問題が。メガネは店で売ってるが。
355:デフォルトの名無しさん
08/08/25 21:41:59
>>354
脳へ渡す情報なら幾らでも買えるが人生は売ってないからね。
356:デフォルトの名無しさん
08/08/26 08:17:51
死ねば負債は清算できるぜ
ES4は修正して継続するようだが。
357:デフォルトの名無しさん
08/08/26 08:23:20
へ？ES4は一旦清算するんでしょ？
やりたきゃES3.1ハーモニーの後にしろと。
358:デフォルトの名無しさん
08/08/26 08:34:14
URLﾘﾝｸ(weblogs.mozillazine.org)
もう Nightly に入ってるって聞いたぜ
359:デフォルトの名無しさん
08/09/03 14:58:15
おまいら的には Chrome よりコッチだよな
URLﾘﾝｸ(code.google.com)
360:デフォルトの名無しさん
08/09/03 15:39:27
もうJITしていられんな
361:デフォルトの名無しさん
08/09/03 19:48:00
V8 はコンパイラオンリーな実装なんだね。
これも JIT に入るのかな。
362:デフォルトの名無しさん
08/09/03 21:38:11
コードざっと見たけども「V8で（だけ）速く動く」書き方がありそうなんだよ
google提供のjavascript(mapsなんか)はそう書き直されるんじゃなかろうか
いわゆるひとつの非関税障壁になりそうな予感
363:デフォルトの名無しさん
08/09/03 21:58:32
ARMあたりに対応してるからそのうちアンドロイドに組み込まれるんじゃないかと
364:デフォルトの名無しさん
08/09/04 00:32:47
>>362
そんなものがない実装なんてないよ。
365:デフォルトの名無しさん
08/09/04 03:40:08
>>362
その懸念はありかもね
他インプリもgoogleのjavascriptを基準に最適化しはじめたりしてね
アホすぎるが
366:デフォルトの名無しさん
08/09/04 10:29:19
ようするに方言が増えて、移植性の壁が高くなっただけだな。
367:デフォルトの名無しさん
08/09/04 11:07:56
修正BSDだから他も全てV8エンジンベースになるんじゃねーの
これだけ速度の違いを見せつけられるとね
368:デフォルトの名無しさん
08/09/04 11:20:04
IEはならない。
firefoxもtamarinがあるし、XULを考えると差し換えはかなりの大作業。
369:デフォルトの名無しさん
08/09/04 19:49:13
Rhinoはもとから十分早いし。
370:デフォルトの名無しさん
08/09/04 23:53:41
>>368
firefox に tamarin が入る目はもはやほとんどないよ
tamarin jit だけ移植して終わり
371:デフォルトの名無しさん
08/09/05 00:27:30
ホント、タマリンはこれからどうするんだろね
372:デフォルトの名無しさん
08/09/05 01:47:29
MLでそんな議論になってる？
373:デフォルトの名無しさん
08/09/05 21:01:13
超超初歩の質問です
document.write("hogehoge");
document.clear();
と書いても、clearを無視されてhogehogeと表示されます。
document内容を動的に消去したいです
374:デフォルトの名無しさん
08/09/05 21:22:59
document.open();
375:デフォルトの名無しさん
08/09/08 13:07:23
>>370-372
> The project was canceled mainly because tamarin-tracing never caught
> up to SpiderMonkey's speed. Tamarin-tracing also would have needed
> a lot of other features to be useful on the web:
URLﾘﾝｸ(wiki.mozilla.org)
(13:32, 4 September 2008 変更)
ML にもアナウンスはなかったと思う
376:デフォルトの名無しさん
08/09/08 21:00:24
tamarin自体を放棄ってことかい
こりゃtamarin
377:デフォルトの名無しさん
08/09/08 23:22:51
chrome/JSv8の影響かな？
378:デフォルトの名無しさん
08/09/09 00:03:54
TraceMonkeyに吸収合併じゃねえの？
379:デフォルトの名無しさん
08/09/09 00:10:46
Adobeカワイソス
380:デフォルトの名無しさん
08/09/09 00:19:04
今のとこ >>370 のとおり Tamarin-tracing の nanojit のみ
TraceMonkey(SpidirMonkey + nanojit) に入れてるだけ。
Adobe が使うから Tamarin-central と Tamarin-tracing の開発は続いてる。
しばらく前に DOM の GC に MMgc(Tamarin の GC) を使うか
jemalloc 利用した GC 作るかって話があったんだが、結論がどうなったか
よくわからん、後者っぽいんだけど…
381:デフォルトの名無しさん
08/09/09 00:31:18
>>378
コードとアイデアを Tamarin-Tracing プロジェクトと共有してるっぽい？
英語つよいひと だれか たすけて
> It is based on a technique developed at UC Irvine
> called "trace trees", and building on code and ideas
> shared with the Tamarin Tracing project.
URLﾘﾝｸ(wiki.mozilla.org)
382:デフォルトの名無しさん
08/09/09 02:31:35
そう。
"trace trees"ってのは、
コード列を木構造にして、JIT対象単位とする手法。
383:190.90.128.210.bf.2iij.net
08/09/10 14:45:40
>>346
>> まぁ議論のベースになってるのはこれ。
>> URLﾘﾝｸ(wiki.ecmascript.org)
> | ModuleName '.' '*' 'as' Ident '*' # all with prefix
こんなの入れるくらいなら、階層を持つモジュール名をprefixにして、
参照できるようにしてくれよ！
384:190.90.128.210.bf.2iij.net
08/09/10 17:15:45
v8のソース、10万行ありますね。
385:p31195-adsau15honb9-acca.tokyo.ocn.ne.jp
08/09/10 20:39:48
tamarinが15万行ぐらいだし普通じゃね？
386:デフォルトの名無しさん
08/09/10 21:53:29
なんでfusianasanなの？
387:385
08/09/10 22:02:18
2chの仕様変更?とnavi2chのバグのあわせ技でした
>>383-384 も同じかも
388:デフォルトの名無しさん
08/09/10 23:27:11
それはすごいSGだなｗ
389:デフォルトの名無しさん
08/09/10 23:29:27
>>387
どこ行けば判る? > 仕様変更
390:デフォルトの名無しさん
08/09/10 23:30:53
ごめん、>>389は無視して。
navi2chのスレと間違えた。
391:デフォルトの名無しさん
08/09/16 22:41:27
js1.9とes3.1はまだかーーー
392:デフォルトの名無しさん
08/09/20 10:23:21
URLﾘﾝｸ(webkit.org)
みんないったい何に追われているのか、この何ヶ月、必死すぎ。
この元気があれば ES4 だって Harmony だって物凄い勢いで実装済みそうだぜ
393:デフォルトの名無しさん
08/09/20 10:53:49
だって、システムソフトウェアでのかつてのCのように、
Javascript/ECMAScriptがUIの世界を支配しそうだから。
394:デフォルトの名無しさん
08/09/20 11:52:22
MacがWindowsを駆逐しそうだしな
395:デフォルトの名無しさん
08/09/20 19:31:19
>>394
マジで！？
396:デフォルトの名無しさん
08/09/20 21:05:28
インタプリタの最終進化まで行きそうだ
397:デフォルトの名無しさん
08/09/21 19:16:30
最初からJavaバイトコード吐いてJavaVMに最適化丸投げ出来るRhinoは楽だな。
deoptimize実装してないVMだと動的プロパティは相性悪そうだが。
398:デフォルトの名無しさん
08/09/22 23:10:53
SquirrelFish Extremeが早いらしいね。
リッチコンテンツ使うからどこも必死か。
399:デフォルトの名無しさん
08/09/25 18:06:04
> ECMAScript Harmony
> Plus, as some JS implementors have noted with concern, multiple open
> namespaces impose runtime cost unless an implementation works
> significantly harder.
これってどこかに具体的な議論ある?
ES4のNamespaceが1st class objectというのはやりすぎだとは思うが、
ほとんど何もできないObjectだから問題が起きそうにもない。
もしかしてName objekutの方で、属するNamespace(qualifier属性)が
immutableになってないことが問題になっているんだろうか。
400:デフォルトの名無しさん
08/09/25 23:05:10
>>399
> これってどこかに具体的な議論ある?
ES4-ML で実装が面倒ってのは何度も出てたけど、これは覚えがない。
> もしかしてName objekutの方で、属するNamespace(qualifier属性)が
> immutableになってないことが問題になっているんだろうか。
そうだと思う。
DOM で
script = document.createElement('script');
...appendChild(script);
のように動的に namespace object を持つスクリプトがロードされたとき、
読み込み元のスクリプトの無修飾の name を読み込まれたものと
衝突しないように、qualifier 属性を再構築しなきゃならなくなる
ということでないかな。
401:デフォルトの名無しさん
08/09/26 00:30:10
文字列と整数の掛け算できるようになった？
402:デフォルトの名無しさん
08/09/26 14:00:07
>>400
え、DOMの名前空間とJavaScriptの名前空間が一緒になるってこと？
じゃないよね？
403:デフォルトの名無しさん
08/09/26 15:34:57
>>402
ちがうちがう。ES4 の import とかだけ使うなら問題はないんだろうけど、
legacy な DOM を介する動的ロードするとコストが増加するってこと。
互換性のことがあるから、切るわけにもいかんのでしょ。
404:399
08/10/01 17:37:31
>>400
返事遅れました。調べてもやっぱりよくわかりませんなあ。
そういう"intern"がmission criticalなコードってそうないだろうし。
少なくとも、
>>346
> まぁ議論のベースになってるのはこれ。
> URLﾘﾝｸ(wiki.ecmascript.org)
この案だって、1st class objectでないもののnamespaceはあるわけで、
Brendan Eichが、URLﾘﾝｸ(ejohn.org)で改めて、
> However, as I noted in my message to the lists,
> namespaces, packages, and early binding are definitely gone.
こう言いきっている意味は分からないな。
namespaceの全くないmoduleなんてありえないもの。
企業の思惑が絡んでくると、分けの分からない議論になるなあ。
ただ、かなり熱い"harmony"だったことは伝わってくるね。
405:デフォルトの名無しさん
08/10/01 23:34:06
> こう言いきっている意味は分からないな。
URLﾘﾝｸ(wiki.ecmascript.org) が
harmony になる前に出された提案(というよりスケッチ)なんで
namespace が残ってる、という単純な話かも。
proposals:modules は macro の言及があるように元々 after ES4 の
ためのものだった。「議論のベース」って言ったのはまずかった、すまん。
いいとこ参照先だ。
> namespaceの全くないmoduleなんてありえないもの。
ES4 のメカニズムにおける namespace がないってことでしょう。
一般的な意味での namespace(パッケージシステム？) をどうするのか
まだ見えないけども、内部構造に namespace を持たない形じゃぁ
ないのかなと思ってる(AST になる段階で namespace が消える)
406:デフォルトの名無しさん
08/10/02 13:54:13
というかnamespaceのないmoduleなんてありえないよ。
FOLDOCより
namespace
A set of names in which all names are unique.
namespaceなしじゃmoduleローカルな識別子も定義できないよ。
namespaceオブジェクトとなると行きすぎだろうけど。
407:デフォルトの名無しさん
08/10/02 14:41:46
>>406
そんなのcoding conventionでmodule nameをprefixとして使うとか、どうにでもできる。
408:デフォルトの名無しさん
08/10/02 14:49:45
elispかよw
409:デフォルトの名無しさん
08/10/02 18:00:02
オブジェクトを名前空間として流用する風習はあるのだから
「Rubyかよ」の方が適切じゃないかね
410:デフォルトの名無しさん
08/10/02 18:06:23
>>409
はあ？「Smalltalkかよ」だろ。
411:デフォルトの名無しさん
08/10/02 21:07:28
ルビ厨はこれだから・・・
412:デフォルトの名無しさん
08/10/02 23:10:09
振り仮名用の5.5ポイント活字ですね、わかります。
413:デフォルトの名無しさん
08/10/03 00:30:48
いきなりだけど || 演算子のハナシ。
function foo(s){
s = s || 'default string';
...
}
みたいな記述をたまに見かけるんだけど、これ問題ない？
s が単に true になっちゃう処理系があってもおかしくない気がするんだけど。
function foo(s){
s = s==undefined ? 'default string' : s;
...
}
ってこれまで書いてたんだけど、上の例のほうが短いし、慣れれば読みやすい気もする。
ただ数値の場合は 0 渡したいときに困るかね？
414:デフォルトの名無しさん
08/10/03 01:34:38
ECMA262より
The production LogicalORExpression : LogicalORExpression || LogicalANDExpression is
evaluated as follows:
1. Evaluate LogicalORExpression.
2. Call GetValue(Result(1)).
3. Call ToBoolean(Result(2)).
4. If Result(3) is true, return Result(2).
5. Evaluate LogicalANDExpression.
6. Call GetValue(Result(5)).
7. Return Result(6).
(中略)
NOTE
The value produced by a && or || operator is not necessarily of type Boolean.
The value produced will always be the value of one of the two operand expressions.
415:デフォルトの名無しさん
08/10/03 03:50:28
たまにどころかprototype.jsはじめそこら中で使われてるべ?
むしろundefinedと==で比較する方がやばくね?
416:デフォルトの名無しさん
08/10/03 04:51:27
> s が単に true になっちゃう処理系があってもおかしくない気がするんだけど。
つまり、undefinedがbooleanとしてtrueに扱われる処理系ってこと？
それはない。
417:デフォルトの名無しさん
08/10/03 07:47:38
9.2 ToBoolean
The operator ToBoolean converts its argument to a value of type Boolean
according to the following table:
InputType Result
Undefined false
(略)
おまけに、
> 4. If Result(3) is true, return Result(2).
return Result(3)ではない。
418:デフォルトの名無しさん
08/10/03 07:52:22
>>415
> むしろundefinedと==で比較する方がやばくね?
やばくないです。長いので省略しますが、11.9.1と11.9.3です。
419:デフォルトの名無しさん
08/10/03 08:17:29
>>413
||は、true/falseじゃなく、元の値を返すという言語仕様だから、大丈夫。
420:デフォルトの名無しさん
08/10/03 10:59:10
>>418
argument.length でチェックしないと意味が変わるでしょ
foo が何をする関数なのかにもよるけど 'default string' なら >>413 の後者は「間違い」
421:デフォルトの名無しさん
08/10/03 11:23:51
言いたいことは一度に言って欲しいな
422:デフォルトの名無しさん
08/10/03 18:33:03
>>418
引数のsはnullかもしれないし、falseかもしれないだろ。ダメじゃん。
423:デフォルトの名無しさん
08/10/03 21:14:58
x64でうごくやつってないものか
424:デフォルトの名無しさん
08/10/03 21:29:09
Rhino
425:デフォルトの名無しさん
08/10/03 21:59:35
413 です、フォローありがとう。
今日、仕事帰りに本屋寄ったら、このスレでお勧めのサイ本売ってて、買ってきたよ。
古い本だと思ってたし、4200円と高いのでスルーしてた。
|| の仕様についてちゃんと載ってたよ。
何冊か入門書読んだけど、単なる論理ORだと思ってたが、違ったんだな。
ただ "" が false に型変換されるって記述もあったので、"" を与えたい場合には
やっぱり今までどおり
s = s==undefined ? "default string" : s;
が良い気がしたよ。ただそれ以外では
s = s || "default string";
って記述もアリなんだな。いやぁ、面白いわ。
ちなみに俺ってIE4, NS4 の頃あたりに一度、JavaScript やってた人なんだわ。
v1.2 までは || が ture になっちまうってサイ本にあって、俺の記憶と一致した。
この週末、頑張ってサイ本読むわ。
426:デフォルトの名無しさん
08/10/03 22:02:35
>>418
いちおう s===undefinded にしなかったのは、s==undefined だと s==null のときにも反応してくれるから。
これは昔から一緒って言うか、定番の書き方だと俺の灰色の脳細胞に残ってた。
っていうか、サイ本、読んでておもしれーな。
427:デフォルトの名無しさん
08/10/03 22:08:57
サイ本って新版でただろ
428:デフォルトの名無しさん
08/10/03 22:43:00
まぢ？ >>427
金曜夜の焼き鳥を諦め、その金で買ってきたのは第5版ってやつなんだが・・・
429:デフォルトの名無しさん
08/10/03 23:47:53
>>428
それで大丈夫よ。427は
> 古い本だと思ってた
にひっかかって注意してくれたんじゃないかな。
焼き鳥で腹を膨らませるよりもよかったと思えることを願っているよ。
430:デフォルトの名無しさん
08/10/03 23:48:06
URLﾘﾝｸ(www.oreilly.co.jp)
第5版出たのは去年だがそれが最新。第3版なら古いけど。
431:デフォルトの名無しさん
08/10/04 00:08:45
>>429-430 ありがと、安心した。
読破したら、美味しい焼き鳥で自分を祝っちゃる！
432:デフォルトの名無しさん
08/10/05 15:51:19
'aaaggfeeeehhh'.split(/(?=(.)\1*)/);
IE6: a,a,a,g,g,f,e,e,e,e,h,h,h
Firefox3: a,a,a,a,a,g,g,g,g,f,f,e,e,e,e,e,e,e,e,h,h,h,h,h,h,h
Chrome: a,a,a,a,a,g,g,g,g,f,f,e,e,e,e,e,e,e,e,h,h,h,h,h,h
どれが正しいんですか？
433:デフォルトの名無しさん
08/10/05 16:41:54
みんなちがって、みんないい。
434:デフォルトの名無しさん
08/10/05 16:49:23
>>432
ほれ、URLﾘﾝｸ(www2u.biglobe.ne.jp)
そういう時は自分の手で動かしてみるんだ
ちなみに俺が 'aahh'.split(/(?=(.)\1*)/) を自分の手で動かしてみたところ、
a,a,a,h,h,h,h となるのが正解という結論に達した
435:デフォルトの名無しさん
08/10/05 18:27:22
>>434
ありがとうございます
1行ずつ解釈していったところ、どうやら同じ結果になったようです
つまりChromeが確かにECMA準拠ということですね・・・
うむむ、勉強になりました
436:デフォルトの名無しさん
08/10/06 09:33:07
rhino: a,a,a,h,h,h,h
tamarin: aahh
437:デフォルトの名無しさん
08/10/06 10:21:03
この辺の話になるのかなぁ
URLﾘﾝｸ(bugs.ecmascript.org)
[RegExp: Change behavior for backreferences to non-participating groups]
URLﾘﾝｸ(web-graphics.com)
URLﾘﾝｸ(web-graphics.com)
URLﾘﾝｸ(mail.mozilla.org)
URLﾘﾝｸ(mail.mozilla.org)
URLﾘﾝｸ(mail.mozilla.org)
438:デフォルトの名無しさん
08/10/06 11:51:29
そこんとこ3.1は今のところ3.0のまま。
439:デフォルトの名無しさん
08/10/06 15:24:51
>>436
ちょｗ tamarin！
tamarinってもうSpiderMonkeyにマージされてんの？
440:デフォルトの名無しさん
08/10/06 16:04:29
spidermonkey: a,a,a,h,h,h,h,h
441:デフォルトの名無しさん
08/10/06 16:09:13
kjsembed(KDE): a,a,h,h
442:デフォルトの名無しさん
08/10/06 16:14:42
v8: a,a,a,h,h,h,h
443:デフォルトの名無しさん
08/10/06 17:03:08
IE/Tamarin/kjsembedはキャプチャ括弧の内容を追加してないんだろうけど
SpiderMonkeyがhを余分に出すのが謎だな
444:こりゃたまらん!
08/10/06 17:25:01
>>443
tamarin> 'aahh'.split(/(?=(.)\1*)/)
aahh
tamarin> print('aahh')
aahh
tamarin> 'aahh'
aahh
445:デフォルトの名無しさん
08/10/06 17:37:28
>>439
>>370 >>375 >>380
446:443
08/10/06 18:28:15
>>444
あ、すまん、まったく分割されてないのね。カンマを脳内補完してた
Tamarin環境がないんだけど['a', 'a', 'h', 'h']ならa,a,h,hと出るんだよね？
447:デフォルトの名無しさん
08/10/06 19:17:53
tamarin> ['1','2','3','4']
1,2,3,4
448:デフォルトの名無しさん
08/10/06 20:56:53
タマランｗ
449:デフォルトの名無しさん
08/10/06 22:33:15
PerlとRubyはv8と一緒だねぇ。
Pythonは分割してくれなかった。
450:デフォルトの名無しさん
08/10/06 23:26:21
なんでjsの正規表現エンジンって独自なんだろう？って所まで遡るわけか
451:デフォルトの名無しさん
08/10/06 23:41:05
正規表現の拡張は許されてるんだから
WebKitとかPCRE使うならPCREの機能フルに提供しろよって感じだな
452:デフォルトの名無しさん
08/10/07 01:16:32
rubyの正規表現は鬼車だっけ
453:デフォルトの名無しさん
08/10/07 11:12:21
PCREは仕様が結構変わるし、
PCREのまんまって仕様は難しいと思う。
今でもブラウザ依存が問題になっているのに。
それから、マッチに失敗した時は、空の配列を返せばいいのに…
454:デフォルトの名無しさん
08/10/07 11:30:25
import pcre.*;
出来るようにならないかなあ。
455:デフォルトの名無しさん
08/10/07 14:04:55
名前空間ってアボーンしたんじゃなかったけ？
456:デフォルトの名無しさん
08/10/07 16:01:35
import pcre;でいいよ、もう。
457:デフォルトの名無しさん
08/10/08 17:35:46
C++0xのregexがECMAScriptの仕様を参照しているから、
こっちが変わったら向こうにも影響するかも。
458:デフォルトの名無しさん
08/10/08 21:12:10
正規表現で?<が使えるようにならないかな
459:デフォルトの名無しさん
08/10/08 22:40:48
>>457
なんでよりによって？混乱すると思うんだが
460:デフォルトの名無しさん
08/10/08 22:47:41
いっそSNOBOLとかIconを標準ライブラリに含めればいいんだよ。
javaあたりがやりそうで怖いけどなｗ
461:not 457
08/10/09 01:09:33
>>459
正規表現文法は数タイプ実装され、フラグで切り替えられて、
そのsyntax_option_typeの中にECMAScriptというのがある。
ただECMA282と明記された上で、さらなる改変部分も明記されているので、
大きな混乱は生じないんじゃないか。
ECMAScriptの仕様でも、もし挙動を変えるとすれば、
互換モードを付けることになるんじゃないかな。
462:デフォルトの名無しさん
08/10/22 15:20:15
262-3rd の 7 節を今ごろ読んでるんだけど、
lex レベルで InputElementDiv と InputElementRegExp のどちらを使うべき文脈か
なんてのは簡単に決められるの？結局きちんとパーズしないと駄目？
463:デフォルトの名無しさん
08/10/22 17:39:15
文脈自由文法とかチョムスキー標準形とか分かりますか?
464:デフォルトの名無しさん
08/10/26 23:31:11
V8からOpenOfficeのUNOに接続できたら汎用言語になる？
465:デフォルトの名無しさん
08/10/26 23:33:04
今でも十分に汎用だよ。
466:デフォルトの名無しさん
08/10/27 00:35:59
Rhinoな俺にはバックのjavaのライブラリが膨大すぎるんだがｗ
LiveConnect最高だ。
467:デフォルトの名無しさん
08/10/27 10:57:21
>>464
やれやれー
468:デフォルトの名無しさん
08/10/27 15:40:22
>>406
ES3.1はグローバルな名前空間一つしか用意しないで、
moduleを導入するみたい。elispやschemeのように。
>>399のような難しい話じゃないみたい。
とにかく仕様を整理しないといけないから、
構文も意味も全くいじらないで3.1を出す。
いじるのは4で入れる。
ただしコンパイル環境と実行環境でそろえないとまずいもの、
静的型チェック、名前空間などは入れたくないということらしい。
URLﾘﾝｸ(ejohn.org)
まあ、静的型チェック、名前空間があろうがなかろうが、
プログラムを書いている時と実行している時の
モジュールの仕様が変わったら、問題は出るはずなんだけど。
それを起こさないためのドメイン名風階層名前空間と
バージョン管理なんだから。
469:デフォルトの名無しさん
08/10/27 23:09:19
>>468
ES3.1 draft に module 関係の言及はないと思うけど…後はいいけど。
470:デフォルトの名無しさん
08/10/27 23:40:47
え？ elisp にモジュール入るの？
471:デフォルトの名無しさん
08/11/21 12:56:07
そういえばActionMonkeyが取りやめになったって、
MozillaがTamarinのGCを使うとかいってたのはどうなったの？
TraceMonkeyのGCはSpiderMonkeyのままなの？
472:デフォルトの名無しさん
08/11/21 13:39:11
>>471
Mozilla Developer Conference 2008 で講演してた浅井さん曰く、
Tamarin の GC 取り込みはやる予定だが Fx 3.1 (Gecko 1.9.1) には入らないんだとさ
Fx 3.2 とか Fx 4 以降になるんじゃないかっていう話だったと思う
詳しく覚えてる人いたら詳細求む
473:デフォルトの名無しさん
08/11/21 14:17:01
Tracing JITも同時に入れるって話じゃなかった?
tamarinのソースを少し読んだがあまりの汚さに驚愕。
入れるの取り止めになって正解。
あまりのことにMozilla弱体化の陰謀かと思ったよ。
Action Scriptの仕様は結構好きなんだが。
474:デフォルトの名無しさん
08/11/21 18:05:33
>>471
URLﾘﾝｸ(wiki.mozilla.org)
URLﾘﾝｸ(hg.mozilla.org)
URLﾘﾝｸ(steps.dodgson.org)
475:デフォルトの名無しさん
08/11/22 12:51:48
3.1にObject.seal()入るんだ。freeze()も。
よかった。
476:デフォルトの名無しさん
08/11/23 05:15:49
前方互換が無くなるだけで不要な機能だろ
無用な方言を増やすだけの概念
477:デフォルトの名無しさん
08/11/23 09:13:33
class, moduleその他、
動的に変って欲しくないオブジェクトのために必要なんだよ。
478:デフォルトの名無しさん
08/11/23 22:17:26
seal も freeze も、Object.defineProperty の糖衣構文だと思う
やってることは「内部プロパティを変更」という点で共通してる
あるととっても便利（特に [[Enumerable]] の変更）
479:デフォルトの名無しさん
08/11/24 03:15:50
便利かどうかなんて訊いた覚えはないがありがとう。
＞“前方互換が無くなるので不要な機能”
forEach とかクラスメソッドは 3.0 でも Array や prototype を事前に拡張することで対応できる。
しかし Object.defineProperty は？
IE6 と IE7 で動かすためには __*** とか適当なプロパティ作って、
forEach をそれを見るような実装で上書きするような実装しか今俺には思い浮かばない。
とここまで forEach がある Array ならいいが
Object には Enumerable 関数は考えられてない（アホだよな）から
for in に対応できるような実装は不可能。
4.0 から 3.1 にした意味は？中の人は何も学習してないんだろうか。
480:デフォルトの名無しさん
08/11/24 11:32:42
>>478
seal, freezeに関しては、
重要なのは提供方法ではなく、
・Objectが[[extensible]]でなくなる
・propertyが[[flexible]]、[[writable]]でなくなる
そのための方法があること。
これでライブラリー内部のエラー処理がずいぶんと楽になる。
ライブラリーユーザ側のデバッグも。
[[enumerable]]に関しては、
今のままではdirty hackの巣窟になりそうで、
何とかしないといけないとは思うけど、
前方互換の問題があるから慎重にやるべきだと思う。
特にメタな仕組みを持つライブラリに影響が大。
for in抽象はもうちょっとうまく整理するやり方があったと思う。
Javaのcontrol invacation syntaxみたいな。
481:デフォルトの名無しさん
08/11/25 02:52:09
Object.forEach みたいな関数が出てきたとして、
Object はルート要素なんだから、全てのオブジェクトに forEach が無いとおかしい罠。
元はと言えば Object をハッシュのように使った“慣習”のツケなんだけど…
482:デフォルトの名無しさん
08/11/25 09:28:53
>>481
> 元はと言えば Object をハッシュのように使った“慣習”のツケなんだけど…
kwsk
実装自体は連想配列なのに、使ってはならない理由があったの？
483:デフォルトの名無しさん
08/11/25 10:03:02
Array のようにちゃんとデータ型として規定されてれば、
メソッドやプロパティの名前空間とぶつかるような実装にはならなかっただろうし、
enumerable のアリナシに四苦八苦することも少なかっただろうって話
484:デフォルトの名無しさん
08/11/25 10:44:37
要はHashとかDictionaryとかいう型を別に作っておけばよかったということだな
中身はObjectとまったく一緒でいいけど
485:デフォルトの名無しさん
08/11/25 10:53:50
特殊な組み込み型を用意するんじゃなくて、
そういうものを実装できる機構があればいい。
[[enumerable]]に関しては、
>>481の言うようにforEachはどのObjectも持つようにして、
for inはforEachメソッドを呼び出すように再整理するのがいいと思う。
Property attributeによる整理で基本的にはうまくいっている。
486:482
08/11/25 12:16:11
thx
> 要はHashとかDictionaryとかいう型を別に作っておけばよかったということだな
言われてみれば激しく同意だなー
487:デフォルトの名無しさん
08/11/25 18:04:15
>>484
そうすると、ESのESたる特徴がなくなってしまいますな。
つーか、それ、何のJavaの亜流？って感じになっちまう。実際なりそうだけど。 orz
488:デフォルトの名無しさん
08/11/26 09:44:23
ボタンAを押すと自動的にボタンBを押すスクリプトはどう書けばよろしいのでしょうか？
489:デフォルトの名無しさん
08/11/26 11:06:05
>>488
click()
たぶんスレ違いだからJavaScriptスレ池
490:488
08/11/26 13:36:50
いえ、ecmaです。
よろしくお願いします
491:デフォルトの名無しさん
08/11/26 13:45:27
ECMAScriptの仕様にボタンはない
492:デフォルトの名無しさん
08/11/26 17:09:54
>>488
スレ違
たぶんこっち↓
+ JavaScript の質問用スレッド vol.67 +
ｽﾚﾘﾝｸ(hp板)
493:デフォルトの名無しさん
08/11/26 18:30:20
> for in抽象はもうちょっとうまく整理するやり方があったと思う。
> Javaのcontrol invacation syntaxみたいな。
> for inはforEachメソッドを呼び出すように再整理するのがいいと思う。
旧 ES4 だと iterator::values() iterator::items() iterator::keys()
とか提案されてたが、ボツったわけでどーすんのやら。
URLﾘﾝｸ(wiki.ecmascript.org)
494:488
08/11/27 12:19:04
ありがとうございます。
行ってみます
495:デフォルトの名無しさん
08/12/07 22:53:28
JScript｢ecmaよ！私は帰ってきたぁー！！｣
496:デフォルトの名無しさん
08/12/26 06:46:44
ECMAScript の仕様書に出てくる "NoIn" って何を意味するんだぜ？
497:デフォルトの名無しさん
08/12/26 10:39:43
>>496
for (＜ここ＞;...;...)
for (＜ここ＞ in ...)
＜ここ＞ の場所では in 演算子を使っちゃ駄目ってこと。
URLﾘﾝｸ(www2u.biglobe.ne.jp)
の note
498:496
08/12/26 16:06:40
>>497
ありがとう。
499:デフォルトの名無しさん
09/01/03 19:39:07
499
500:デフォルトの名無しさん
09/01/03 19:39:27
500
501:デフォルトの名無しさん
09/01/24 21:01:52
ナットシェルのgood partが翻訳されて並んでたよ。
いい本だからお勧め。
502:デフォルトの名無しさん
09/01/30 23:17:06
宣伝乙
503:デフォルトの名無しさん
09/01/31 00:05:19
いやいや久々のECMA的Javascript本ですよ。
504:デフォルトの名無しさん
09/01/31 07:53:26
宣伝乙
505:デフォルトの名無しさん
09/01/31 10:33:12
2chの悪い癖だよね。
すぐに「社員」だの「工作員」だの。
506:デフォルトの名無しさん
09/01/31 11:40:47
>>505
ただの相槌だから、
全く無反応よりはまし、と思っとけばよい。
507:デフォルトの名無しさん
09/01/31 14:21:57
しかしnew使うなって言われるとちょっと違和感あるな。
個人的には関数はlowerCamel、コンストラクタはUpperCamelで
名づけるという「規約」をしみこませればそれでいいと思うんだけど。
508:デフォルトの名無しさん
09/01/31 14:42:22
使うなとは書いてないよ。
>>507は読んでるから知っているだろうけど、
コンストラクタをnewなしで読んで、グローバルなthisを変更するミスを防ぐために、
UpperCamelでnew向けに書かれていることがはっきり分かるようにするといい。
もっといい対処方法はnewを使わないこと。
と"bad parts - new"の節に書いてある。
「ミスを防ぐためには」が前提の工夫の話。強制はしてない。
509:デフォルトの名無しさん
09/01/31 18:31:13
なんで関数はlowerCamelなの？
キモい
510:デフォルトの名無しさん
09/01/31 19:27:27
new 自体は使っているが、それを「見せないように」する、というハナシが書いてある（Object.create を実装するときに内部で new 使ってる）
ちなみに、Object.create は ECMASCript 3.1 の WD で定義されてる
511:デフォルトの名無しさん
09/01/31 20:47:27
ファクトリメソッドってやつか。俺はnewの方が好きだな。
512:デフォルトの名無しさん
09/01/31 21:17:29
var a = new Hoge();
と
a = {};
a.prototype = Hoge;
Hoge.call(a);
って等価？
513:デフォルトの名無しさん
09/01/31 21:49:53
call()の第一引数は関数として呼び出すしcall()は戻り値がundefindだから別じゃない？
514:デフォルトの名無しさん
09/01/31 21:51:02
ミス:call()は戻り値がundefind
call(a)は戻り値がundefind
515:デフォルトの名無しさん
09/01/31 22:38:18
>>512は改めて見ると間違ってた
var temp = {};
temp.__proto__ = Hoge;
Hoge.call(temp);
var a = temp;
これなら等価かな？
516:デフォルトの名無しさん
09/01/31 22:48:51
temp.prototype();
でいいけどね。
517:デフォルトの名無しさん
09/02/01 17:10:33
すみません、教えてください。
↓のように二次元配列mを定義してwebブラウザのdocument.writeで
表示させてみると、定義の仕方によって表示が異なるのはなぜでしょうか。
また、【2】のように定義した場合でも、mに書式を与えて出力する関数を
書かずに【1】のように表示させる方法はあるでしょうか。
【1】リテラルで定義
var m = [ [ 1, 2 ], [ 3, 4 ] ];
document.write( m ); // 1,2,3,4 と表示
【2】コンストラクタで定義
var m = new matrix ( [ 2, 2 ] ); //要素が空の2x2配列を生成
hoge(m); //適当な関数で各要素に数値を代入
document.write ( m ) // [object Object] と表示
//matrixの定義
function matrix (size) { //sizeは[行数、列数]の形の配列
var i;
this.length=size[0];
for (i=0; i<size[0]; i++) { this[i]=new Array(size[1]) };
}
518:デフォルトの名無しさん
09/02/01 17:32:16
>>517
1はArray.prototype.toString()の結果でそうなる。
2はmatrix.prototype.toStringを定義してないから
結果的にObject.porototype.toString()が使われる。
519:デフォルトの名無しさん
09/02/02 20:37:36
4月でRhinoリリース10周年
520:デフォルトの名無しさん
09/02/02 23:40:19
まじ？もうそんなたつの？
521:デフォルトの名無しさん
09/02/03 01:23:33
MocaScript時代入れるととっくに10年過ぎてるSpiderMonkeyも思い出してあげてください。
522:デフォルトの名無しさん
09/02/03 01:25:38
Spidermonkeyのソース読むと目眩するわ。
Connect, connect、どんだけ接続すんのかと。
523:デフォルトの名無しさん
09/02/03 10:21:17
なに、NN5のソースに比べたらｒｙ
524:デフォルトの名無しさん
09/02/03 13:40:32
mozilla関連のソースコードはもはやレガシーコード
いわばバベルです
525:デフォルトの名無しさん
09/02/03 16:04:10
Fx4 (Mozilla 2) でその辺り整理するんだっけか
526:デフォルトの名無しさん
09/02/03 19:47:38
Firefoxのコード見たらなんかキモかった
527:デフォルトの名無しさん
09/02/03 23:47:37
NN5のソース見たらもっときもいぞ。
そもそもWinMain自体間違ってるとか・・・
528:デフォルトの名無しさん
09/02/04 22:42:13
サイ本を超えるJavaScript(EcmaScript)本って出ないんだろうな。
そこまでいったら仕様書暗記しろレベルなんだろうな。
529:デフォルトの名無しさん
09/02/04 23:49:10
俺はgood partがECMAscript本のベスト1だと思うよ。
530:デフォルトの名無しさん
09/02/06 00:45:07
URLﾘﾝｸ(journal.mycom.co.jp)
> 【速報】Opera新JavaScriptエンジンCarakan発表、50倍高速化も
URLﾘﾝｸ(daniel.gredler.net)
> JavaScript Performance: Rhino beats IE? (daniel.gredler.net)
531:デフォルトの名無しさん
09/02/06 17:18:18
OperaはCSSもそうだが特定の目的にのみ特化して最適化されてるから鵜呑みにしない方が良い。
汎用で早い部類に入るのはRhinoのコンパイルモードくらい。
532:デフォルトの名無しさん
09/02/06 23:07:17
>>531
・Opera同士の比較である
・SunSpiderという標準的なベンチを使ってる
ということで、一行目はちょっと的外れかも。
533:デフォルトの名無しさん
09/02/09 18:13:39
good PartsはDouglas Crockfordが著者だっけ？
JSONとかAjaxとかアホらしい。
534:デフォルトの名無しさん
09/02/09 20:19:58
>>533は先入観が激しくてプログラマには向いてないな。
535:デフォルトの名無しさん
09/02/11 06:38:44
いや、俺もAjaxは今やるのアホらしいと思う。
DOM-level3が全部勧告されてからにしたい。
イベントモデルが標準化されんことには……
536:デフォルトの名無しさん
09/02/11 09:26:15
やる・やらないを技術の内容で決めてどうすんのさ。手段でしかないのに。
まぁ、やりたくない→やらなくて済む ならそれはそれで幸せだが。
537:デフォルトの名無しさん
09/02/11 11:50:51
手段でしかないなら、普通はその技術の内容で
やる・やらないを決めると思う
538:デフォルトの名無しさん
09/02/11 12:09:44
やりたいことがやれるかどうか、じゃねえの？
539:デフォルトの名無しさん
09/02/11 13:03:41
Good Partsは、Ajaxのことは書いてない本
>>533はそういうことには触れてないくだらないボヤキ。
540:デフォルトの名無しさん
09/02/11 13:04:30
やるやらないじゃなくて
やれるやれないじゃないの？
541:デフォルトの名無しさん
09/02/11 15:53:06
>>535
今から歩いて、道を作っておくのも悪くない。
542:デフォルトの名無しさん
09/02/11 15:53:48
ハムレットかよ！
543:デフォルトの名無しさん
09/02/11 16:56:03
この流れは……
XMLHttpRequest（とXMLDocument）が
ECMAの組み込みオブジェクトになるフラグですか？
544:デフォルトの名無しさん
09/02/11 17:14:23
>>543
どの流れか知らんがW3CがDOM/XHRをEcmaに
移管するという話は聞かないしそれはないだろうな。
それよりも URLﾘﾝｸ(journal.mycom.co.jp)
でモジュール読み込み周りが決められたら、それと
ES Harmonyのモジュール周りとがどう関係してくるか気になる。
545:デフォルトの名無しさん
09/02/11 17:59:15
>>543
Modules 原案
URLﾘﾝｸ(docs.google.com)
URLﾘﾝｸ(mail.mozilla.org)
１月のミーティングでは好印象、作業も少しはじめてる？
Dave Herman 自身は気になる所もあるようだが、詳細不明。
546:デフォルトの名無しさん
09/02/11 22:32:03
そもそもJavaScriptだけがなぜかEcmaで標準化されたのか？
W3Cがやっておけば関連仕様との調整もスムーズに行きそうなのに。
DOMとかXMLHttpRequestって絶対言語に食い込んで来ると思うんだが。
jsは元々DOMを操作するための言語だったし、js1.4で仕様が切り離されるまでは・・・。
547:デフォルトの名無しさん
09/02/11 22:54:36
W3CはJavascript否定路線だったもん。
W3C自体今はかなりやばい立場だし。
548:デフォルトの名無しさん
09/02/11 23:12:37
W3CはNTTのせいでNGNが完全にバズワードになってるのがｶﾜｲｿｽ｡
549:デフォルトの名無しさん
09/02/13 08:08:13
Compact Profileはeval入ってないのか。
JSONじゃなくXMLだけでAjaxやれってこと？
550:デフォルトの名無しさん
09/02/13 14:52:04
JSONはes4で読み込みライブラリが付くはずだったけど3.1はどうなるんだろう。
551:デフォルトの名無しさん
09/02/13 15:22:36
>>549>>550
いつの話をしてるの？
Ajaxなんてまるで想定してないのがES-CP。
URLﾘﾝｸ(www.ecma-international.org)
552:デフォルトの名無しさん
09/02/13 22:30:12
>>549
Compact Profile の考えを Security 関連に絞って再構築しているのが
Secure ECMAScript。これも eval がない。
URLﾘﾝｸ(wiki.ecmascript.org)
>>550
Draft as of 09 Feb 2009 だと JSON 関連は生きてるが
URLﾘﾝｸ(wiki.ecmascript.org)
553:デフォルトの名無しさん
09/02/13 23:41:25
>>551
もう3.1はこのドラフトで殆んど出来上がってるように見えるんだが
あと何が足りないんだ？ さっさと勧告してほしい。
遅れれば遅れるほどIEのJS2の実装が延びる……
554:デフォルトの名無しさん
09/02/13 23:47:27
MSが実装をどうするかなんて標準化作業の進み具合とはあまり関係ないだろ。
直接MSにこれはこうだからこうしろと文句いうほうが10倍は影響力がある。
555:デフォルトの名無しさん
09/02/13 23:48:48
IEなんざapplication/ecmascriptどころか
application/javascriptすら読み込まないじゃねーか
当分無視でいいだろ。
556:デフォルトの名無しさん
09/02/14 00:27:01
>>553
IEのスケジュールに影響するから早くしろって言うのか?
557:デフォルトの名無しさん
09/02/14 00:52:02
JScriptなんて元々眼中にない。
Ecmaに限ったことじゃないが今まで散々標準に準拠しなかったのが最近になって対応をやってるが
ブラウザ界だとIE8を超えれば落ち着くだろう。（もちろん、ろくな標準準拠は果たせず）
XML関連はもっと悲惨だろう。
今の実装を捨てない限り永久にまともな実装は出てこないだろう。
結果、相も変わらずIEは無視したいができない現状が続くかと・・・。
558:デフォルトの名無しさん
09/02/14 06:20:35
IEの何が悲惨って、
実装が糞のくせにOS組み込み型だから
アップデートが遅いのが一番悲惨
Chromeみたいに一定周期で安定版を
出してくれれば、まだ救いがあるのに
559:デフォルトの名無しさん
09/02/14 08:13:14
IEならWindowsUpdateがあるじゃないか
ただ大田総理が「今までできてたことができなくなるからUpdateイラネ」って言ってた。
560:デフォルトの名無しさん
09/02/14 09:21:14
敢えてアップデートはせずに脆弱性突かれ放題にしておくんですね。分かります。
561:デフォルトの名無しさん
09/02/14 09:40:18
大田総理が言いたいのは
「今まで脆弱性を突き放題できてたことができなくなるから皆がUpdateするのイラネ」
ってことじゃね
562:デフォルトの名無しさん
09/02/28 11:19:06
stringオブジェクトについて少し質問です。
標準仕様にあるtoLowerCaseメソッドとtoLocaleLowerCaseの違いについて知りたくて調べております。
標準仕様によると
> 正規 Unicode 文字マッピングで言語の規則が干渉する (たとえばトルコ語のような) ごく一部の文字でのみ違いが存在する。
とありますが、この文章の意味はいったい何なのでしょうか？
最初はドイツ語のウムラウト(Ü)等、英語のアルファベット以外も正しく小文字に変換するのだろうと思っていたのですが
ドイツ語やフランス語でも(toLowerCaseメソッド/toLocaleLowerCase)の双方で結果が同じでした。
キリル文字(ロシア語)のグレイヴ付きЕ、グレイヴ付きИだけ、ブラウザごとに違いが出ました。
正直浅学を恥じますが、少々でも知識のある方いらっしゃいましたらご教授お願いいたします。
563:デフォルトの名無しさん
09/02/28 12:20:34
実装依存じゃないのかな。
564:デフォルトの名無しさん
09/02/28 13:18:10
トルコ語の例というのは多分Iとİのことでしょう。
通常ならIの小文字はiですが、トルコ語にはIの他にİという文字があり、
iは後者の小文字として扱われます。
I → ı
İ → i
この辺をきっちり処理するのがtoLocaleLowerCaseなのではないかと。
565:562
09/02/28 15:28:43
なるほど、そうなると日本語を選択した環境では
「I」、「İ」共に小文字のiが返るのが仕様上正しいのですね。
一応各ブラウザ上での動作です。
IE:I→i,İ→İ
Firefox:I→i,İ→i
Opera:I→i,İ→i
Saari:I→i,İ→i
ieだけlocaleLowerCaseで大文字のİが返ります。
グレイヴ付きЕ、グレイヴ付きИでの変換の結果が違うのは、マイナー文字なので対応が遅れているだけなのでしょう。
566:デフォルトの名無しさん
09/02/28 17:41:38
そういやString.toLocaleString()って仕様上はロケールに合わせた文字列を返すんだよな。
SpiderMonkeyの実装だとObject.toLocaleString()はtoString()を返してArray,Number,Dataしかオーバーライドされてないんだが結局これも実装依存なんだろうか？
567:562
09/02/28 23:38:57
> Object.prototype.toLocaleString()
> この関数の最初のパラメータは、この標準の将来のバージョンにおいて使用されそうである
とあるので、Objectではこれで良いのでしょう。
Arrayは、飛ばして議論をすると
Date
> ホスト環境の現在のロケールの慣習に該当する形式の Date の表現が意図される。
Number
> この関数は実装依存で、 toString と同じものを返すことを許可されているが推奨もされない。
となっているので、仕様では何も定めていませんね。実装依存でしょう。
しかし、実際に調べてみるとブラウザ毎にまちまちになっていますね。
document.write( (1000).toLocaleString() +"<br />" );
document.write( (new Date()).toLocaleString() +"<br />" );
Dateオブジェクト
IE 1,000.00
Firefox 1,000
Opera 1000
Safari 1000
Numberオブジェクト
IE 2009年2月28日 23:16:34
Firefox 2009年2月28日 23:14:51
Opera 2009/02/28 23:16:00
Safari Saturday, February 28, 2009 23:15:29
見た感じではFirefoxが一番頑張っていて、Opera、Safariは日本語環境を考えていない印象を受けますね。
これは日本語環境下での動作でしょうから、他言語ではどうなるのかが気になりますが…
568:デフォルトの名無しさん
09/02/28 23:46:55
そのOperaの日付表記は、明らかに日本語環境の短い形式でしょう。
569:デフォルトの名無しさん
09/02/28 23:58:00
ちなみにC#(というか.NET)でこういうことすると、こういう表示になる。
-----
Console.WriteLine(DateTime.Now.ToString(new CultureInfo("ja-jp").DateTimeFormat));
Console.WriteLine(DateTime.Now.ToString(new CultureInfo("en-us").DateTimeFormat));
Console.WriteLine(DateTime.Now.ToString(new CultureInfo("en-gb").DateTimeFormat));
-----
2009/02/28 23:56:31
2/28/2009 11:56:31 PM
28/02/2009 23:56:31
570:デフォルトの名無しさん
09/03/01 00:37:11
yyyy/mm/dd time方式ってRFCになかったっけ？
それかどこかで標準化されてないっけ？
んで結局>>567はString.toLocaleString()の話をしてないのはなんで？
#Data.prototype.toLocaleString()はSwatch Internet Timeを返すべきだと思うんだ。ブラウザの実装だしとかいってみるｗ
571:デフォルトの名無しさん
09/03/01 01:02:22
ISO8601にある。
572:デフォルトの名無しさん
09/03/01 01:07:01
ISO8601で'/'は範囲(期間)を示すから違うのでは？
2009-03-01T01:05:23+09:00って形式でしょう。
573:567
09/03/01 07:38:14
なんだか知らない単語が吹き出してきて少し困りました…
とりあえず、ちょっとだけ整理のために…
Object.toLocaleString()はオーバーライドされるために定義されてだけなのでtoString()と同じで良いし
Array.toLocaleString()は、他のオブジェクトのtoLocaleStringで文字列化してから連結する、なのでこれは無視して良い。
なので問題はDateとNumberオブジェクトでどうするかなのだと思うのです。
仕様を読むと次の様になっています
> Date.toLocaleTimeString()
> この関数は文字列値を返す。文字列の内容は実装依存であるが、現在のタイムゾーンの、簡便で人間に読解可能な、ホスト環境の現在のロケールの慣習に該当する形式の Date の "date" 成分の表現が意図される。
> Number.toLocaleString()
> ホスト環境の現在のロケールの慣習に沿って整形される Number の値を表す文字列値を生成する。この関数は実装依存で、 toString と同じものを返すことを許可されているが推奨もされない。
「2009-03-01T01:05:23+09:00」の形式に関してはHTMLの[DATETIME]形式ですね。
URLﾘﾝｸ(www.asahi-net.or.jp)
ISO8601に関してはググったらwikipediaに該当項目がありました
URLﾘﾝｸ(ja.wikipedia.org)
私の場合は、ロケールの慣習に該当するというのは「○月×日」みたいな感じに返してくれるのが正しい様な気がしたのですが、んー知識不足です。正直言って。
574:567
09/03/01 10:45:13
あとすいません忘れてました。String.toLocaleStringは標準仕様では存在していなかったです。
なのでプロトタイプチェーンを手繰ってObject.toLocaleStringを呼び出しているはず…。
575:デフォルトの名無しさん
09/03/01 12:40:31
>>573
おかしいよその仕様。どこで見たの?他と取り違えてるかコピペミスしてるよね。
原文を当たるまでもないが、一応:
URLﾘﾝｸ(www.ecma-international.org)
15.9.5.7 Date.prototype.toLocaleTimeString ( )
This function returns a string value. The contents of the string are implementation-dependent, but are
intended to represent the “time” portion of the Date in the current time zone in a convenient, humanreadable
form that corresponds to the conventions of the host environment’s current locale.
576:574
09/03/01 15:51:10
あ、申し訳ございません。
ご指摘のとおり、私のコピペミスですね。
Date.toLocaleString()の方をコピペすべきだったのですが…。
原文と邦訳の方載せておきます。
URLﾘﾝｸ(www2u.biglobe.ne.jp)
> この関数は文字列値を返す。文字列の内容は実装依存であるが、現在のタイムゾーンの、簡便で人間に読解可能な、ホスト環境の現在のロケールの慣習に該当する形式の Date の表現が意図される。
> NOTE この関数の第一引数は、この標準の将来のバージョンで使用される可能性がある; 実装はこのパラメータを他の用途に使用しないことを推奨される。
> 15.9.5.5Date.prototype.toLocaleString()
> Thisfunctionreturnsastringvalue.Thecontentsofthestringareimplementation-dependent,butare
intendedtorepresenttheDateinthecurrenttimezoneinaconvenient,human-readableformthat
correspondstotheconventionsofthehostenvironment*fscurrentlocale
> NOTE
> Thefirstparametertothisfunctionislikelytobeusedinafutureversionofthisstandard;itis
recommendedthatimplementationsdonotusethisparameterpositionforanythingelse.
みなさま、申し訳ありませんでした。
577:デフォルトの名無しさん
09/03/06 23:02:44
3.1の仕様ﾏﾀﾞｰ?
578:デフォルトの名無しさん
09/03/07 03:22:26
>>577
WD 読んで我慢しる
URLﾘﾝｸ(wiki.ecmascript.org)
579:デフォルトの名無しさん
09/03/19 16:07:40
ははは
580:デフォルトの名無しさん
09/03/27 16:29:12
ES3.1がECMAScript第五版だってさ！
URLﾘﾝｸ(blog.360.yahoo.com)
581:デフォルトの名無しさん
09/03/29 18:43:32
ES4は欠番なのかぁ
582:デフォルトの名無しさん
09/03/29 19:53:53
>>580は滅茶苦茶重いサイトだな
583:デフォルトの名無しさん
09/03/29 22:18:55
ES4には絶対しないって意思の現れだね。
584:デフォルトの名無しさん
09/03/29 22:21:43
次は3.14だな
585:デフォルトの名無しさん
09/04/02 16:48:57
ActionScriptとの統合もなさそうだなあ
586:デフォルトの名無しさん
09/04/02 20:12:10
>>583
作者死亡と共にバージョンπになるんですね
587:デフォルトの名無しさん
09/04/02 20:26:34
クヌースは何歳まで生きられるんだろう？
588:デフォルトの名無しさん
09/04/02 23:19:35
>>587
長寿の血統ではあるらしい。
589:デフォルトの名無しさん
09/04/10 12:40:35
ES5(ES3.1) candidate draft
URLﾘﾝｸ(www.ecma-international.org)
発行は今年12月か…
590:デフォルトの名無しさん
09/04/18 23:06:48
スレチかも分からんけど、ECMAScriptってMIMEでバージョン指定できたっけ？
たとえばapplication/ecmascript;version=3.0みたいな。
できないと3.1が出てからクロスブラウザ対策が面倒になるんだよなー。
591:デフォルトの名無しさん
09/04/19 01:01:02
>>590
URLﾘﾝｸ(www.ietf.org)
592:デフォルトの名無しさん
09/04/29 18:21:55
ActionScriptはどうなっちゃうの？
593:デフォルトの名無しさん
09/04/29 19:35:46
ASがESに合わせて仕様を変えるんだろ。
594:デフォルトの名無しさん
09/04/30 21:36:27
なんというなみだ目
595:デフォルトの名無しさん
09/05/03 00:11:57
先走りすぎただけだ。
ASはASで生き残るかもよ
596:デフォルトの名無しさん
09/05/08 13:57:13
ActionScriptはいいところ一杯あったけど、
開発者メーリングリストとソースコードを読んで、
大雑把な仕様策定に汚いコードでびっくりした。
擁護する気が萎えた。
597:デフォルトの名無しさん
09/05/08 17:56:38
完全に振り回されたなASは
AS2のような
AS3仕様で開発可能なES5準拠のAS4を出してくれｗ
598:デフォルトの名無しさん
09/05/09 01:59:12
jQueryを今頃発見してるけど、なんとなく動的にDOM管理するのに
慣れない。 PHPでCSSのクラスかいていい気になってたんじゃ
とてもじゃ無いけどやってけんらしい。
599:デフォルトの名無しさん
09/05/11 16:31:14
見放されたASプログラマがGnashに集結して・・・・って展開はないかな
600:デフォルトの名無しさん
09/05/11 16:45:33
終結してどうすんだよ
AS書くのとAS実装を書くのは全然違うぞwww
601:デフォルトの名無しさん
09/05/12 00:58:08
終結とは巧いじゃないか
602:デフォルトの名無しさん
09/07/10 21:57:17
セルフコンパイラというものがあってだな
603:デフォルトの名無しさん
09/07/25 01:30:12
rhino 1.8ﾏﾀﾞｰ?
ジェネレータ式ないとコード長すぎる。
604:デフォルトの名無しさん
09/08/01 00:21:20
DoJo の話題はこのスレで良いですか？
605:デフォルトの名無しさん
09/08/01 00:21:58
DoJo の話題はこのスレでよいですか？
606:デフォルトの名無しさん
09/08/01 00:33:57
DocomoのJava環境のこと？
最近のは知らないが違うんじゃないかな。
607:デフォルトの名無しさん
09/08/01 02:03:45
>>606
チミが場違い
と言われかねんぞ その発言はw
608:デフォルトの名無しさん
09/08/01 04:20:14
>>604
>>2
609:デフォルトの名無しさん
09/08/01 12:56:41
>>604-605
きっとボケたんだよ。
「どうじょ(どうぞ)」って返してほしかったんだと思う。
イマドキJavaとJavaScriptを混同するようなやつはいねーよ。
610:デフォルトの名無しさん
09/08/03 12:43:32
この板に張り付く様な奴は、JavaとJavaScriptを混同することは無いと思うが、
デザイナ上がりの自称Webプログラマーとかいう奴で、JavaとJavaScriptの区別のつかない奴にあった事ある（3人程）。
その内一人は、客先でJSをJavaとか言う出すもんだから「弊社のサーバではJavaは実行できない」とか客に言われて、
訂正の連絡を入れる羽目になった。
そいつは、もうオレと同じ職場に居ない...
611:606
09/08/03 16:08:48
なんか俺のせいで変な方向にスレがすすんでる。
dojoをdojaに見間違えてただけなんだが、
正直すまんかった。
dojoはAjaxなどへのjavascriptの応用技術なんだが、
このスレは言語規格を扱うスレなんでスレ違いということ。
612:デフォルトの名無しさん
09/08/04 01:51:27
> dojoはAjaxなどへのjavascriptの応用技術なんだが、
痛々しいぜ
613:デフォルトの名無しさん
09/08/04 12:55:08
えっ？
ネタでスレをだらだらと進めているかと思って楽しんでいたのだが...
マジっすか！
614:デフォルトの名無しさん
09/09/04 20:21:28
MozillaとRhino以外にJS1.8に対応の処理系ってあるの？
615:デフォルトの名無しさん
09/09/04 20:53:00
JS1.8の拡張はESと関係ないからスレチじゃね
616:デフォルトの名無しさん
09/09/05 00:08:44
617:デフォルトの名無しさん
09/09/05 02:50:39
>>2に
>このスレでは、★言語★としてのECMAScript(JavaScript、JScript等)の話題を扱います。
って書いてあるからOKかと思ったんだけど
618:デフォルトの名無しさん
09/09/05 03:39:06
だーかーらー
JS1.8ってECMAの仕様と関係無いﾓｼﾞﾗの独自拡張だろって言ってんだよ
JavaScript関係なら専スレがこの板にもあるからそっち池
619:デフォルトの名無しさん
09/09/05 03:45:40
>>618
それ言いだしたらJScriptとか独自拡張の産物だろｗ
JavaScriptスレはここにwebネタを持ち込まないための隔離スレ以外のなにものでもない
新スレ立っちゃったのが正直残念
620:デフォルトの名無しさん
09/09/05 04:09:28
>>619
独自拡張も何も、JScriptとJavaScriptは本来別物だろう
ECMAScriptって呼べるのは後から作られた標準規格に当たる部分と、E4X拡張だけ
最新バージョンのJavaScriptやJScriptに対して、ES規格は標準化のためのサブセットであって
ES規格からはみ出た部分はそれぞれの独自拡張でしかない
621:デフォルトの名無しさん
09/09/05 05:53:07
622:デフォルトの名無しさん
09/09/05 06:51:27
×独自拡張の産物
○ゲイツのエゴの産物
Rhinoはまだjs1.8対応してないぜ
>JScriptとJavaScriptは本来別物だろう
JScriptは別物だがjsはルーツだからべつものではないだろ。
ecma-262はjsの共通仕様にすぎん。
ecmaは
その共通仕様部分以外関与しない方針なんで実質ベンダーの仕様とその実装されたエンジンの話が出てくるのは仕方がない。
まあJavaScriptってもDOMとLiveConnectはスレチだろう。
623:デフォルトの名無しさん
09/09/07 15:14:23
今更だがJS/UIX面白いな
URLﾘﾝｸ(www.masswerk.at)
しかしアドレスバーや内部のデバッガから
直接いじれるからすぐに(ry
メソッドやプロパティの隠蔽って出来ないのかな
624:デフォルトの名無しさん
09/11/07 02:47:40
URLﾘﾝｸ(ja.wikibooks.org)
何回目かの書き込みスイマセン
時々追記や修正を行ってくださる方がいて、心がほっこりするのですが
基本孤独な戦場な感じなので、できればお仲間を募集中です
625:デフォルトの名無しさん
09/11/07 08:27:55
仕様書丸暗記して出直して来い。
間違えだらけで書き切れんわ。
626:デフォルトの名無しさん
09/11/07 12:16:39
>>624
2年くらい前に見て、ないほうがよかったと思ったやつだな
627:デフォルトの名無しさん
09/11/07 13:11:08
>>624
すべてがハッシュとして記録される、っていうのは
仕様として決まってたっけ……？
628:デフォルトの名無しさん
09/11/07 18:36:54
いや、見た目がハッシュなだけで内部の実装に影響する記述はない。
Object objectがハッシュ風にアクセスできるだけ。
プロパティのインデックスでもアクセスできるのにハッシュだと定めると都合悪いっしょ。
629:デフォルトの名無しさん
09/11/07 18:53:51
整数以外のインデックスでアクセスできるのが、
ハッシュテーブル・インターフェースの特徴でしょ。
630:デフォルトの名無しさん
09/11/07 19:59:09
それは連想配列の特徴だな
そしてハッシュテーブルによる実装が主流とはいえ手法は他にもある
例え現存する全てのECMA実装がハッシュテーブルを選択していたとしても
仕様として決まっているとは言えない
631:デフォルトの名無しさん
09/11/07 22:59:06
Rhinoだと効率重視なのか自前のハッシュだった。
632:デフォルトの名無しさん
09/11/08 10:50:20
ツリーによる実装でもいいしね。
633:デフォルトの名無しさん
09/11/08 19:28:52
es5のFunction.prototype.bind()とかObjectのプロパティ操作系拡張って誰得？
プロパティ操作が標準化されるのはまだいいが。
バインドとかいまでも当たり前の機能でしょ？
そんなことより
var calc = (function(){
var a=0;
this.func = function(x){
return a + x;
}
return {
inc : function(){
return func(1);
}
}
}
)();
calc.inc();
こんなコード書かなきゃプライベートなメンバ定義できないのを何とかしてくれ。
634:デフォルトの名無しさん
09/11/08 20:05:43
クラス指向はes4と一緒に死んだんだよ。
635:デフォルトの名無しさん
09/11/08 20:09:35
クラスが作れないのに「私をクラスにして」と言わんばかりの文法だからイライラするw
636:デフォルトの名無しさん
09/11/09 12:29:35
AdobeのActionScriptは独自路線を突き進んでいますが、
これをECMAが取り入れてほしいともうのだが、駄目だろうか？
時期、Flash CS5 では、なんとiPhoneのプログラミングもできてしまうというので、
ActionScriptのバージョンも上がるかもしれない。
ECMAScriptの未来はActionScriptの中にあるとおもうのだが、どう思うだろうか？
637:デフォルトの名無しさん
09/11/09 17:35:27
>>636
iPhone用のプログラミングができることと、ActionScriptの仕様は別の話
あれは確かActionScriptをObjective Cにコンバートするような代物だったはず
あと、ActionScriptが採用したES4仕様案は廃棄されたから、ぶっちゃけお先真っ暗
次期ECMAScriptは5（旧3.1）になるし、一部ES4仕様も5に入ってるから、それでいいんじゃない？
638:636
09/11/10 12:37:41
>>637
>あれは確かActionScriptをObjective Cにコンバートするような代物だったはず
そうだったんですか！勘違いしていました。
実際、ActionScriptのお先真っ暗というお話を聞いて、少し悲しくなりました。
ECMAScriptの進化はゆっくりしているようですが、
HTML5がメジャーになれば、今よりも速いスピードで進化していくのでしょう。
そうしたら、ActionScriptも淘汰されてしまうのでしょうね...orz
639:デフォルトの名無しさん
09/11/11 10:04:38
HTML5とECMAScriptは関係ないよ
そこゴッチャにするとまともな議論なんかできない
ひと昔前にW3C DOMとECMAScriptをゴッチャに考えてた輩と同じ思考してない？
ActionScriptがどうなるかは、次期ActionScriptがどうなるかと、Flashをとりまく情勢がどうなるかで決まると思う
世の中にはHTML5とFlashを同列に語ってるバカも多いけど、そもそも大元が違いすぎるから比較するだけ無駄
何だかんだでHTMl5とFlashはうまく棲み分けされてくんじゃないかな
結局、ActionScript自体はまだ残り続けていくだろうよ
640:デフォルトの名無しさん
09/11/12 13:39:18
Edition 5(旧称3.1)は来月にもECMAで承認、そのままファストトラックで
JTC1へ提出されるそうだ。
URLﾘﾝｸ(www.ecma-international.org)
641:デフォルトの名無しさん
09/11/12 15:39:09
>>640
> It is anticipated that this will result in a fast-track submission to
> ISO/IEC JTC 1 for revision of ISO/IEC 16262.
JTCってなにかと思ったけど、ISO/IECの話か
ECMAに送付されるバージョンは
URLﾘﾝｸ(wiki.ecmascript.org)
の一番上にある"Final TC39 Approved Draft"でいいのかな？
このドラフト、ECMAに出す出さないの瀬戸際になってからバグFixされまくってたから
まだ何か潜んであるんじゃないかと心配になる・・・
642:デフォルトの名無しさん
09/11/12 16:42:53
そういや、JavaScriptが標準化されてること自体がマイナー知識だけど
ISO/IEC JTC1でも標準化してるって更にマイナーな知識だよな
JIS規格ともなると、読んだことのある開発者はいるのかっていうレベル
643:デフォルトの名無しさん
09/11/12 19:19:26
JIS に規格票はかなりやる気ないな
644:デフォルトの名無しさん
09/11/12 20:03:20
なんにせよ来月には公開ってことか。めでたい。
645:デフォルトの名無しさん
09/11/12 21:18:30
規格気にする奴ならマイナーな知識でもないと思うが
普通はそもそも標準化って何ってレベルか
646:デフォルトの名無しさん
09/11/12 23:58:33
え、JISにもjavascriptあるの？
JIS X 3014みたいな翻訳じゃなくて？
正直ecmaとmozillaの仕様以外どうでもいいなぁ。
オープンスタンダードとデファクトスタンダード記憶しとけば問題ないし。
まあjs1.1 - 1.8.1とJScriptとECMA-262 ed.3は覚えてるけど。
647:デフォルトの名無しさん
09/11/13 00:42:31
翻訳っつーとTRとかと誤解されそうだが、まあ、JISのはただの翻訳だ。
JavaScriptじゃなくECMAScript。Wikipediaにもいつのまにか載ってるな
648:デフォルトの名無しさん
09/11/13 12:22:53
標準規格は「絵に描いた餅」。
読むだけ時間の無駄。
649:デフォルトの名無しさん
09/11/13 20:46:00
>>648
その絵に描いた餅を元にJavaScript2.0が作られる予定ですけど？
650:デフォルトの名無しさん
09/11/14 17:08:16
絵に描いた餅を現実化するのが実装者の仕事
餅を作るのに毎回絵から描き直してたらそれこそ時間の無駄だろ
651:デフォルトの名無しさん
09/11/14 18:10:37
じゃあ、読むのは時間の無駄じゃねーじゃん
652:デフォルトの名無しさん
09/11/16 11:52:29
>>648
じゃあECMAScript実装に貢献してくれ
MozillaでもAppleでもいいからさ
それはそうと、JISのほうってWeb上で公開されてたっけ？
それとも、よくある「金出して冊子買え」商法になってる？
653:デフォルトの名無しさん
09/11/16 15:44:58
jis検索でググれ
654:デフォルトの名無しさん
09/11/16 20:36:49
>>652
JISC とかいう組織のサイトで見れるよ。
但し、保存も印刷も出来ない細工をしてるつもりらしい。
実際にはこのスレ見てるような人なら簡単になんとか出来るだろうけどな。
どういうわけか見れる pdf は文書をラスタ画像化したものになってるので、
微妙にキタナい。 検索も出来んし。
655:デフォルトの名無しさん
09/11/17 00:28:38
大変アレなお知らせだが、そのJISCこそがISOにおける我が国の代表だ。
URLﾘﾝｸ(www.iso.org)
656:デフォルトの名無しさん
09/11/17 00:40:45
>654
っていうか一般人でも印刷は普通に出来る。
わざわざハックしなくても、スクショ（ｒｙ
657:652
09/11/17 11:14:18
>>654
完全に失念してた！ありがとう
URLﾘﾝｸ(www.jisc.go.jp)
中身は色々と残念すぎるので見なかったことにしたい・・・
658:デフォルトの名無しさん
09/11/17 13:44:13
翻訳くらいしろよと小一時間問い詰めたい
659:デフォルトの名無しさん
09/11/21 19:57:35
prototype.jsってECMAScript仕様に適合してる？
それともJavaScriptの拡張も使ってる？
分かる人いたら教えてくれ。
660:デフォルトの名無しさん
09/11/22 00:36:33
クロスブラウザな時点でわからないならｒｙ
661:デフォルトの名無しさん
09/11/22 06:14:33
$を平気で使ってる時点で察しろ
662:デフォルトの名無しさん
09/12/01 13:46:52
誰だよ単発のRhinoスレ立てた馬鹿は？
javascriptスレの連中か？
663:デフォルトの名無しさん
09/12/05 15:51:05
5th来たよー
URLﾘﾝｸ(www.ecma-international.org)
ドラフトはdocでも公開されてたけど正式版はpdfだけなの？
664:デフォルトの名無しさん
09/12/07 14:09:54
で、5版の規格ではどんな機能が追加されたの？
教えて偉い人
665:デフォルトの名無しさん
09/12/07 17:31:45
嫁！
666:デフォルトの名無しさん
09/12/11 22:24:42
どうかFirefoxのスクリプトの後方互換性ができるだけ失われませんように……
667:デフォルトの名無しさん
09/12/12 20:52:56
言語仕様が変わらなくてもDOMの方で変わっていくから・・・
668:デフォルトの名無しさん
09/12/12 20:54:54
なにやってもどうせIEが糞実装だから心配するな。やるべきことは変わらん。
669:デフォルトの名無しさん
09/12/14 10:45:03
ES3に毛が生えた程度のES5で
後方互換性が気になるような書き方をしていたのなら
豆腐の角に頭ぶつけた方がいいぞ
670:デフォルトの名無しさん
09/12/14 14:09:02
誰得メソッド満載な仕様が嫌だ！
671:デフォルトの名無しさん
09/12/14 17:27:56
ECMAScript 5th Editionで改善された3rd Editionの項目
URLﾘﾝｸ(d.hatena.ne.jp)
672:デフォルトの名無しさん
09/12/29 17:48:39
"use strict";
673:デフォルトの名無しさん
10/01/12 17:04:39
ecma5でもオブジェクトのプライベートメンバー作れないのかよ
あとgoto文も使えないな
674:デフォルトの名無しさん
10/01/12 19:36:41
なんでgoto文いれるんだろう?
JSでyaccでも書かせるのかな
675:デフォルトの名無しさん
10/01/20 15:35:02
ES5にgotoないよね？
使えないってuselessではなくunavailableの意味だよね？
676:デフォルトの名無しさん
10/01/28 17:23:26
>>664
URLﾘﾝｸ(www.infoq.com)
677:デフォルトの名無しさん
10/03/04 19:12:57
カウチdata baseって大規模なwebでも使えるものなの？
678:デフォルトの名無しさん
10/03/26 17:16:16
Errorオブジェクトは例外の種類は分かるけど
どこで例外が投げられたか分からないのが糞
679:デフォルトの名無しさん
10/04/01 18:56:03
SpideMonkeyで配列内包をwithの中で使ったときの動作がおかしい気がするんだけど
alert([i*i for each(i in [1,2,3])]); //OK
with({}){
alert([i*i for each(i in [1,2,3])]); //ReferenceError: i is not defined
}
680:デフォルトの名無しさん
10/04/09 23:49:24
letも分割代入もできるJS1.7でwithを使う奴の気がしれん
681:デフォルトの名無しさん
10/04/21 23:50:06
with,Call,ClosureはNetscapeからの贈り物。
importとexportは取り込んで良かったと思う。
682:デフォルトの名無しさん
10/08/10 17:59:05
URLﾘﾝｸ(www.publickey1.jp)
IE9からはJavaSciptの対応バージョンは最新のECMAScript 5th Edition（ECMAScriptとは、
JavaScriptの基となる仕様の名称）準拠となっているようですが、
IE9 Platform Previewに対するフィードバックにより、ECMAScript 5th Editionの仕様のバグを発見しています。
具体的には、ECMAScript 5th Editionの仕様とそれ以前のECMAScriptで
動作に違いがあることがIE9 Platform Previewにより発見され、
過去との互換性維持のためにECMAScript 5th Editionの仕様のアップデートにつながったとのことです
（詳細は「How IE9 Platform Preview Feedback Changed the JavaScript Standard」参照）。
683:デフォルトの名無しさん
10/08/19 23:39:56
>JavaSciptの対応バージョンは最新のECMAScript 5th Edition準拠
でもJScriptなんでしょ。
MSお得意の仕様には準拠したけど実装は・・・てやつ。
最近はこの手口止めて自分とこの仕様をECMAに投げて標準化してるけどECMAScriptだけは入り込む隙ないからな。
入り込もうとするたびに実装を利用してるコミュニティの猛反発食らってるし。
3Eが形変えただけってのは皆分かってるからなぁ。
684:デフォルトの名無しさん
10/08/22 22:53:57
意味が分からん。標準仕様に完全に準拠してるなら、別にそれ以外の独自拡張をしたっていいじゃん。
それともまさか名前がJavaScriptじゃないことを叩いてんの？
685:デフォルトの名無しさん
10/08/23 20:14:00
なんで独自拡張が混乱の元になるかも分からんゆとりか？
だいたいIEの場合、標準仕様に完全に準拠は絶対にない。
686:デフォルトの名無しさん
10/08/23 22:14:37
独自拡張を全否定したらWEBの発展が見込めないってこともわからんゆとりか。
完全準拠してないならまずそこを穿ってけばいいのに。
687:デフォルトの名無しさん
10/08/23 22:19:42
ecmaの仕様の話するスレで独自拡張布教するなよ。
688:デフォルトの名無しさん
10/08/23 22:21:53
独自拡張に依らないウェブの進化を目指してたXHTML2がこけちゃったもんな
689:デフォルトの名無しさん
10/08/24 10:09:47
つか、WHATWGが「どうせ俺らが実装しなきゃ絵に描いた餅なんだから、
仕様は俺達で作るわ、XHTML使いづれーし」って言って、W3Cが涙目で応じたじゃん？
つまり、MSの独自拡張の時代はずっと前に終わってて、
WHATWGが実装ありきで仕様を作り、W3Cがそれを勧告するっつー流れ。
690:デフォルトの名無しさん
10/08/29 09:14:09
ecmascriptで相互再帰って出来るの？
普通の再帰にフラグを渡してその値で場合分けするみたいな
微妙なやり方しか思いつかないんだけど
691:デフォルトの名無しさん
10/08/30 12:00:01
出来るので頑張ってください。
微妙な実装になるかどうかはあなたのセンス次第です。
692:デフォルトの名無しさん
10/08/30 19:06:37
function f(){
return g();
}
function g(){
return f();
}
あばばばばば。
693:デフォルトの名無しさん
10/08/30 19:55:05
∩＿＿＿∩ ｜
| ノ＼ ヽ |
/ ●゛ ● | |
| ∪ ( _●_) ミ j
彡､ |∪| | Ｊ
/ ∩ノ ⊃ ヽ
( ＼ ／ ＿ノ | |
.＼ “ ／＿＿| |
＼ ／＿＿＿ ／
694:デフォルトの名無しさん
10/08/31 14:59:13
wikiとか見たけど混乱したんで教えてください
ECMAScript5thがJavaScript1.9で実装されてて(firefox4)
ECMAScript4thがJavaScript2.0(JScript/ActionScript)っていう認識はあってますか？
それとも2009/12に策定されたECMAScript5thのことをJavaScript2.0って呼んでいて
ECMAScript 4thは仕様策定放棄され
JScript/ActionScriptはECMAScript4thの草案を実装してるだけ(JavaScript2.0ではない)なのでしょうか