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
ありがとうございます。
行ってみます