- 1 名前：デフォルトの名無しさん [2007/09/19(水) 09:08:01 ]
- 《ECMAScriptを語るスレ》
1. - 概要 -
ECMA-262規格として知られる言語（通称 ECMAScript）についての利用法や言語仕様、
その他四方山話をするスレです。
- ECMA-262 3rd Edition 標準規格（英語）-
www.ecma-international.org/publications/standards/Ecma-262.htm
Under Translation of ECMA-262 3rd Edition (日本語訳)
www2u.biglobe.ne.jp/~oz-07ams/prog/ecma262r3/
前スレ
ECMAScript デス 2
pc11.2ch.net/test/read.cgi/tech/1088298991/
過去スレ
JavaScript デス
pc5.2ch.net/test/read.cgi/tech/1052273054/
- 883 名前：デフォルトの名無しさん mailto:sage [2011/10/05(水) 20:04:41.64 ]
- > ボブ「そうさpricelessさ！」
タダほど高いものはない
ってことですかボブ
- 884 名前：デフォルトの名無しさん mailto:sage [2011/10/05(水) 20:56:31.37 ]
- LispやPython使ったらええがなって思います
- 885 名前：デフォルトの名無しさん mailto:sage [2011/10/05(水) 21:09:43.30 ]
- >>883
マジレスしていいのか。
それと「アメリカの通販番組はpricelessly」とかけてる。
MCのCMがpricelessで〆てたからさHAHAHA
- 886 名前：デフォルトの名無しさん mailto:sage [2011/10/05(水) 21:24:54.55 ]
- >884
CommonLisp/SchemeはとっつきにくいしPythonは標準規格がない
よし、ここはRubyをだな……
- 887 名前：デフォルトの名無しさん mailto:sage [2011/10/05(水) 21:37:50.00 ]
- pythonに標準規格がないとかいう文句初めて見たわ
- 888 名前：デフォルトの名無しさん mailto:sage [2011/10/05(水) 22:09:24.59 ]
- 2004年のものだけど。
WHY Common Lisp?
cl-www.msi.co.jp/solutions/knowledge/lisp-world/articles/why-lisp
> ANSI, ISO あるいは JIS で現実的な仕様の決まっている programming 言語と
> いうものはそう多くなく、わたしに思いつくものはCOBOL, FORTRAN, ADA,
> PL/1, C/C++, Common Lisp くらいしかありません。どれも一応 PC も含めた複
> 数の platform で動いていますが、この中で例えば web server を現実的なコ
> ストで書けるものは何か、と尋ねたら C/C++ か Common Lisp に落着く。
>
> したがって、どの programming 言語を使いますか?という問いは、
>
> gc のない C/C++ と、それを持つ Common Lisp の、どちらを使いますか?
>
> という問いと同値です。
- 889 名前：デフォルトの名無しさん mailto:sage [2011/10/05(水) 23:35:15.47 ]
- rubyは組み込むにはでかすぎる。信者があまりにもキモすぎるで論外。
- 890 名前：デフォルトの名無しさん mailto:sage [2011/10/06(木) 00:57:52.87 ]
- ECMAScriptの文法とどっこいどっこいじゃね＞キモい
それに信者は言語と関係ないし
- 891 名前：デフォルトの名無しさん mailto:sage [2011/10/06(木) 01:16:50.19 ]
- >>888
当時すでにESは標準化されてるのに見事にスルーしてるのがひどい……
ほかにも今のところIEEEのSchemeとか、ECMAのC#とか
ISOならSmalltalk、Prolog、Eiffel、Modula-2、Forthなんかがあるな
Rubyも一応今ならJISがあるし、ISOにファストトラックで送られてる最中
Haskellみたいなのも一応標準化されてると言えるのかな
- 892 名前：デフォルトの名無しさん mailto:sage [2011/10/06(木) 01:50:29.44 ]
- 仕様なんてなくたって次期gcc4.6に組み込まれることになった
golang さんのことも忘れないでくださいね…
- 893 名前：デフォルトの名無しさん mailto:sage [2011/10/06(木) 04:56:47.88 ]
- >>891
要するに実装に縛られたくないんだろうけどlisp使いたいだけの後付だよね
- 894 名前：デフォルトの名無しさん mailto:sage [2011/10/06(木) 06:31:00.43 ]
- プロパティに名前空間つかんのかの
- 895 名前：デフォルトの名無しさん mailto:sage [2011/10/06(木) 10:50:06.18 ]
- c# みたいにならないかそれ delphi とか pascal みたいにいったほうが
正確か…昔の葉名前空間と言うよりモジュール名で管理というかんじだけど
- 896 名前：デフォルトの名無しさん mailto:sage [2011/10/07(金) 02:27:49.65 ]
- オブジェクトが名前空間に属すなら
それを参照するプロパティも同じプレフィクスを持つとか
- 897 名前：デフォルトの名無しさん mailto:sage [2011/10/07(金) 14:24:23.42 ]
- >>882
Rhinoよく使うけどyieldとかletが使えるようになってたこと知らなかった。
ありがとう。
でもgenerator式はまだなんだね。
- 898 名前：デフォルトの名無しさん mailto:sage [2011/10/08(土) 00:19:18.22 ]
- >>897
js1.8自身ジェネレータまわりの変更がメインだからだと思う。
Rhinoで使えるバージョン=rhinoのバージョン数+サポートしたと言っている言語仕様バージョンの一部て感じだからspidermonkeyと同期してるわけじゃないよ。
Rhino1.7R3の変更ってes5準拠とCommonJSサポートのが目立つしね。
組み込み用途だとjs object実装がjava collectionsとして扱えるようになったから便利になったよ。
- 899 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 09:26:39.29 ]
- javascriptのアンチテーゼのはずのDartが見事なjavascript1.5なのは仕様面で見てどう思うよ？
- 900 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 12:31:15.46 ]
- Dartがjs1.5というのは分からないけどこのクソ言語だけは絶対に流行って欲しくない
- 901 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 13:18:10.06 ]
- DartもCoffeeも一緒に滅んでくれ
あと激重jQueryもな
jsごとき1から10まで手書きできなくてどうする
- 902 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 13:40:38.05 ]
- ついでにECMAScriptも滅べばいいのに
- 903 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 14:00:14.77 ]
- Dartがボロクソに叩かれまくって、じゃあブラウザにvm乗せてもう好きな言語で開発できるようにしようぜって流れになればいい
- 904 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 22:29:08.63 ]
- IEは好きなスクリプト言語を自由に追加できる設計だった
IE6は登場時点ではほんとに超先進的ブラウザだったんだよ
- 905 名前：デフォルトの名無しさん mailto:sage [2011/10/13(木) 03:59:40.91 ]
- >>903
java plug-inの出番だな。CommonDOMだけじゃなくLiveConnectもjava plug-inの管轄になったから次はブラウザ用の言語か。
- 906 名前：デフォルトの名無しさん mailto:sage [2011/10/13(木) 12:15:58.05 ]
- > ...このクソ言語だけは絶対に流行って欲しくない
> ついでにECMAScriptも滅べばいいのに
こういうアンチ野郎が多い言語は、不思議と普及してしまうというマーフィーの法則
- 907 名前：デフォルトの名無しさん mailto:sage [2011/10/13(木) 14:03:13.55 ]
- 出たばかりのLiveScriptもいじり倒して遊んでるギーク以外重いからやめろって結構言われてたよ。
そのときからcallerまわりは問題視されてたけどnetscapeには黙殺されて今までズルズルやってんよ。
- 908 名前：デフォルトの名無しさん mailto:sage [2011/10/13(木) 21:14:27.79 ]
- ECMAScript.next: the “TXJS” update by Eich
ttp://www.2ality.com/2011/06/esnext-txjs.html
- 909 名前：デフォルトの名無しさん mailto:sage [2011/10/14(金) 14:36:11.77 ]
- Dartのすごさがイマイチわからんけど
よく見る「ECMAScriptのセミコロン省略が良かった／悪かった」てのは
単純にHTMLのonclick="..."とかでセミコロン不要にするってだけのものだろ？
onclickにDartを書きたいときとか、どう区別すんの
- 910 名前：デフォルトの名無しさん mailto:sage [2011/10/14(金) 16:12:09.46 ]
- >>909
www.dartlang.org/articles/embedding-in-html/
- 911 名前：デフォルトの名無しさん mailto:sage [2011/10/14(金) 16:54:56.59 ]
- >>910
なるほどね
こりゃ、だめだわ
- 912 名前：デフォルトの名無しさん mailto:sage [2011/10/14(金) 17:14:23.36 ]
- ん、htmlタグの属性値中でセミコロン使うと何か問題あるんだっけ？
- 913 名前：デフォルトの名無しさん mailto:sage [2011/10/14(金) 21:19:50.77 ]
- HTML5の仕様によるとonclickにはJavaScriptしか書けないので
そもそも考慮無用
- 914 名前：デフォルトの名無しさん mailto:sage [2011/10/15(土) 00:44:43.61 ]
- >単純にHTMLのonclick="..."とかでセミコロン不要にするってだけのものだろ？
そもそもこれが間違ってる。
分かりきったものをだらだらと書かせるなよって事。型推論いいよねと似てる。
他の言語だとxml地獄、rubyでend地獄やpythonのインデント強制によるエントロピー増加が問題なわけ。
省略したらしたでjsみたいな問題も出てくるし、jsの場合はセミコロンの省略が言語仕様にあるからそれとは別問題。
たんにセミコロン省略できない言語メインが省略便利といってるだけ。
- 915 名前：デフォルトの名無しさん mailto:sage [2011/10/15(土) 01:21:58.33 ]
- >>914
すまんが何言ってるかちょっとわからん
まーあれだ、イベントハンドラのrobustnessの重要性にjQueryもやっと気づきはじめたところに
document.query(...).on.click.addとか、また黒歴史を繰り返すのかよって感じ
ライブラリの問題だからスレ違いだけどな
- 916 名前：デフォルトの名無しさん mailto:sage [2011/10/15(土) 04:26:27.99 ]
- dartスレのjQuery厨か？
- 917 名前：デフォルトの名無しさん mailto:sage [2011/10/16(日) 18:54:33.85 ]
- Dartスレなんてあったのかよ
なんでここで議論してんだ
- 918 名前：デフォルトの名無しさん mailto:sage [2011/11/25(金) 19:39:31.74 ]
- JDKのjavascript実装がJDK7でrhino1.7R3に変わっとる。
デフォルトの言語バージョンが1.8で特権コード書かないと変更できないようになってるがJDK8でnashornに変えるのに互換性大丈夫だろうか。
これはもしかしてnashornが1.8準拠なのか？
spidermonkeyもjs1.8.xでes5準拠だしやっと最新仕様で早い実装が来るかもしれんな。
- 919 名前：デフォルトの名無しさん mailto:sage [2011/12/13(火) 13:10:41.45 ]
- VB6.0のScriptControlでDMDScriptを使おうとしています。
www.digitalmars.com/dscript/download.html
の「DMDScript binaries」をダウンロードしました。
ScriptControl1.Language="DMDScript"でエラーにはならないので
認識はされているようなのですが、
ScriptControl1.Eval("1+1")で何も返してくれません。
JScriptとVBScriptはもちろん、PerlScriptとRubyScriptで
ちゃんと値を返したのですが
DMDScriptはScriptControlから呼び出されるEvalに対する
インターフェース(?)を実装していないのでしょうか?
- 920 名前：デフォルトの名無しさん mailto:sage [2011/12/14(水) 05:26:38.70 ]
- APIの実装固有はスレチ。
javascriptスレがあるがjs互換じゃなくてJScript互換なDMDScriptも対象かは知らん
- 921 名前：デフォルトの名無しさん mailto:sage [2011/12/15(木) 09:14:23.79 ]
- 412 ：デフォルトの名無しさん [↓] ：2011/12/14(水) 18:41:16.34
なんでプログラム板にこのスレがあるんだ
413+1 ：デフォルトの名無しさん [↓] ：2011/12/14(水) 18:48:12.24
JavaScriptがブラウザ以外の環境でも使われだしたから。
418 ：デフォルトの名無しさん [↓] ：2011/12/15(木) 07:49:36.32
jsはブラウザによって挙動が異なるけど、これはjsで言うところのクライアント（エージェント)ねたになるのでweb系板扱い。そもそもム板ではブラウザの挙動などまったく興味ないし誰も知らない。
419 ：デフォルトの名無しさん [↓] ：2011/12/15(木) 08:20:30.49
>>413
それならブラウザで使用するJavaScriptの話をここでするのはおかしいんじゃないの
420 ：デフォルトの名無しさん [↓] ：2011/12/15(木) 08:37:54.15
ム板でjsスレがあってもおかしくないけど、ブラウザねた(jsコンパイラの実装レベルの違い)や
ブラウザ依存（xml/domなどの処理クラス・オブジェクトのサポートがブラウザ別にある・ないなど）の話題が中心になるは興味ないしそういうtipsコードはプログラムに関係ないからこの板では勘弁してほしい。
421 ：デフォルトの名無しさん [↓] ：2011/12/15(木) 08:54:50.81
いくつか乱立してるからそのうち一つにまとめると2ch jsコミニティーとして成立するだろうね。
【node.js】サーバサイドjavascript【Rhino】
みたくクライアントサイドの議論じゃないってことを付けとくと勘違い者とかまぬけ者は無理にスレに入ってこないだろう。
俺はインタプリタでrhinoを使ってるからjavaにも精通する必要があるしcgi,httpserver,streamなんかも当然に理解してる必要があるけど、ブラウザでやるならmozilla,webkit,chromeのjs実装が中心でms-ieはweb板扱いになるんじゃないか。
423 ：デフォルトの名無しさん [↓] ：2011/12/15(木) 09:11:26.52
ECMAScript デス 3
hibari.2ch.net/test/read.cgi/tech/1190160481/
が、ム板のjs本スレか。じゃそっちに集約するし移動するか。
- 922 名前：デフォルトの名無しさん mailto:sage [2011/12/15(木) 12:58:05.22 ]
- >>918
jdk6 rhinoは御承知のようにJavaAdapterがサン実装なのですが、rhino script上でjava class abstractを継承したjs funtionまたはabstractを直にnewしたようなインスタンスはどうやって作ればいいでしょうか。
- 923 名前：デフォルトの名無しさん mailto:sage [2011/12/20(火) 01:48:43.81 ]
- node のせいで let、yield使えないv8のjsが流行ってるけど、
どうしてこうなった。
明らかにMozilla側の実装の方がよかった…。
- 924 名前：デフォルトの名無しさん mailto:sage [2011/12/20(火) 11:02:48.62 ]
- このスレで言うことじゃない。
- 925 名前：デフォルトの名無しさん mailto:sage [2011/12/23(金) 14:50:49.73 ]
- letやyieldはMozillaの独自実装
断じて先行実装ではない
多分
- 926 名前：デフォルトの名無しさん mailto:sage [2011/12/23(金) 17:49:32.07 ]
- 先行＝独自です。
ただし、letなんかはharmonyの後でも議論が続いていて入る見込みが大いにあります。
wiki.ecmascript.org/doku.php?id=harmony:block_scoped_bindings
(function (){ 〜 })();とか
new function (){ 〜 };とか馬鹿馬鹿しいし。
- 927 名前：デフォルトの名無しさん mailto:sage [2011/12/23(金) 19:13:57.92 ]
- 本家とはいえ、Mozillaのオラオラ実装っぷりはIEを笑えん
- 928 名前：デフォルトの名無しさん mailto:sage [2011/12/23(金) 19:19:08.58 ]
- そうだそうだ
しかるべき組織が策定した仕様から実装しろ！
- 929 名前：デフォルトの名無しさん mailto:sage [2011/12/23(金) 19:41:56.23 ]
- そりゃC++をみてから言えよ
イニシアチブを一社がとって進むほうが
結果的にいいものが出来るよ
熟成したら独立組織に移管がよか
- 930 名前：デフォルトの名無しさん mailto:sage [2011/12/23(金) 20:23:08.81 ]
- C++はStroustrupが指揮棒握ってるよ。
JavascriptでEichのやらせたharmonyレベルの仕事は常にしてる。
委員会で仕様を策定しているのが原因だと思うのは言語をよく理解できてないから。
- 931 名前：デフォルトの名無しさん mailto:sage [2011/12/23(金) 20:26:15.10 ]
- IE6の時代が最もいい時代だったってこった
- 932 名前：デフォルトの名無しさん mailto:sage [2011/12/24(土) 17:49:47.25 ]
- MSは前に立つとボロがでるから
後ろからついてく会社
- 933 名前：デフォルトの名無しさん [2011/12/27(火) 05:35:05.97 ]
- どうしてECMAScript 4が駄目になったのかつくづく理解できない。
あれさえ通っていればJavaScriptが主流になることに異議はなかった。
2011年になってまだ新しいモジュールの書き方生み出していてどうするんだよ。
waka.hatenablog.com/entry/2011/11/27/215627
このまま本格的に使われるようだと、保守不能なコードが際限なく量産されるぞ。
CoffeeScriptならどうにかなるんかとおもいきや
フォラーム覗いたら、どうすんだよ、どうにもなんねーと揉めてる有様
2005年のスライド↓
「最後に生き残るのはJavaScriptかもな」
eto.com/d/PresenShibuyaJS.presen
完全に的中しているし、確かに生き残ったが、言語としてまるっきり停滞したまま生き残るとか
まして主流にしようとかありえないだろ。
正直、この10年かJavaScript界隈にいて日々バッドノウハウを生み出して喜んでた連中、
言語そのものをどうにかしようとしなかった連中を全員殴ってまわりたいレベル
- 934 名前：デフォルトの名無しさん mailto:sage [2011/12/27(火) 05:45:21.04 ]
- Googleが素直にECMAに沿って実装してればなあ。
- 935 名前：デフォルトの名無しさん mailto:sage [2011/12/27(火) 08:16:43.80 ]
- >>933
まだ本格的には使ってなくて眺めてる状態だけどひでえ書き方だな
プログラミング界隈じゃよくあるけど妄信的な連中が大声で喚いて何も進まない
- 936 名前：デフォルトの名無しさん mailto:sage [2011/12/27(火) 08:28:59.86 ]
- >>933
つ Dart
- 937 名前：デフォルトの名無しさん mailto:sage [2011/12/27(火) 08:44:54.83 ]
- Dartは信者も苦笑い。
- 938 名前：デフォルトの名無しさん mailto:sage [2011/12/27(火) 12:01:46.95 ]
- 4を無理に通してたらバベルの塔再来になってた。
慎重に合意取り付けてくのは当たり前。
今でも非互換性が問題になって、
$(document).readyとかやってるのに。
それから4の機能の殆どは継続審議されてる。
HTML5界隈でも標準化が順調に進んでる。
- 939 名前：デフォルトの名無しさん mailto:sage [2011/12/27(火) 21:33:42.89 ]
- blogs.msdn.com/b/ie_jp/archive/2011/12/27/10251140.aspx
Math.coshとかMSは何をやってるんだ…
- 940 名前：デフォルトの名無しさん mailto:sage [2011/12/27(火) 22:20:17.73 ]
- 大規模な JavaScript
大規模なアプリケーションを構築する場合、高品質なオーサリング機能やツールの活用が不可欠になります。
そのような場合は、クラスなどの高度な抽象化およびその他の一般的なプログラミング パターンを基盤として、
ツール利用のエクスペリエンスを向上させることができます。
数十万行の JavaScript コードから成る Office Web アプリケーションは、主に Script# をベースに記述されており、
JavaScript にコンパイルされ、今日の各種ブラウザーで実行できるようになっています。
Google Web Toolkit などのツールセットも同様のアプローチを採っています。
最近では、Traceur や CoffeeScript などの変換コンパイラ ライブラリによって、
JavaScript への追加構文や、完全な代替構文も、今日のブラウザーでランタイムへの変更なしに処理可能なことが実証されています。
JavaScript には基本的な欠陥があり、これらのシナリオをサポートするには JavaScript の構文およびランタイムからの “決別” が必須であると予告する向きもあります (Dart の例など)。
私たちはこうした見解には同意しません。
TC39 委員会の参加者として、標準ランタイムを拡張し、大規模な JavaScript 開発のサポートに必要な構文機能を既存の JavaScript 標準の上に構築できると確信しています。
- 941 名前：デフォルトの名無しさん mailto:sage [2011/12/28(水) 00:18:05.15 ]
- 今更ECMAScript 4を持ちだすやつのFlash臭
- 942 名前：デフォルトの名無しさん mailto:sage [2011/12/28(水) 23:15:02.26 ]
- >>926
Mozillaの独自実装とは違った仕様になる可能性大だけどな
|
 |
