11/10/14 16:54:56.59
>>910
なるほどね
こりゃ、だめだわ
912:デフォルトの名無しさん
11/10/14 17:14:23.36
ん、htmlタグの属性値中でセミコロン使うと何か問題あるんだっけ？
913:デフォルトの名無しさん
11/10/14 21:19:50.77
HTML5の仕様によるとonclickにはJavaScriptしか書けないので
そもそも考慮無用
914:デフォルトの名無しさん
11/10/15 00:44:43.61
>単純にHTMLのonclick="..."とかでセミコロン不要にするってだけのものだろ？
そもそもこれが間違ってる。
分かりきったものをだらだらと書かせるなよって事。型推論いいよねと似てる。
他の言語だとxml地獄、rubyでend地獄やpythonのインデント強制によるエントロピー増加が問題なわけ。
省略したらしたでjsみたいな問題も出てくるし、jsの場合はセミコロンの省略が言語仕様にあるからそれとは別問題。
たんにセミコロン省略できない言語メインが省略便利といってるだけ。
915:デフォルトの名無しさん
11/10/15 01:21:58.33
>>914
すまんが何言ってるかちょっとわからん
まーあれだ、イベントハンドラのrobustnessの重要性にjQueryもやっと気づきはじめたところに
document.query(...).on.click.addとか、また黒歴史を繰り返すのかよって感じ
ライブラリの問題だからスレ違いだけどな
916:デフォルトの名無しさん
11/10/15 04:26:27.99
dartスレのjQuery厨か？
917:デフォルトの名無しさん
11/10/16 18:54:33.85
Dartスレなんてあったのかよ
なんでここで議論してんだ
918:デフォルトの名無しさん
11/11/25 19:39:31.74
JDKのjavascript実装がJDK7でrhino1.7R3に変わっとる。
デフォルトの言語バージョンが1.8で特権コード書かないと変更できないようになってるがJDK8でnashornに変えるのに互換性大丈夫だろうか。
これはもしかしてnashornが1.8準拠なのか？
spidermonkeyもjs1.8.xでes5準拠だしやっと最新仕様で早い実装が来るかもしれんな。
919:デフォルトの名無しさん
11/12/13 13:10:41.45
VB6.0のScriptControlでDMDScriptを使おうとしています。
URLﾘﾝｸ(www.digitalmars.com)
の「DMDScript binaries」をダウンロードしました。
ScriptControl1.Language="DMDScript"でエラーにはならないので
認識はされているようなのですが、
ScriptControl1.Eval("1+1")で何も返してくれません。
JScriptとVBScriptはもちろん、PerlScriptとRubyScriptで
ちゃんと値を返したのですが
DMDScriptはScriptControlから呼び出されるEvalに対する
インターフェース(?)を実装していないのでしょうか?
920:デフォルトの名無しさん
11/12/14 05:26:38.70
APIの実装固有はスレチ。
javascriptスレがあるがjs互換じゃなくてJScript互換なDMDScriptも対象かは知らん
921:デフォルトの名無しさん
11/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
ｽﾚﾘﾝｸ(tech板)
が、ム板のjs本スレか。じゃそっちに集約するし移動するか。
922:デフォルトの名無しさん
11/12/15 12:58:05.22
>>918
jdk6 rhinoは御承知のようにJavaAdapterがサン実装なのですが、rhino script上でjava class abstractを継承したjs funtionまたはabstractを直にnewしたようなインスタンスはどうやって作ればいいでしょうか。
923:デフォルトの名無しさん
11/12/20 01:48:43.81
node のせいで let、yield使えないv8のjsが流行ってるけど、
どうしてこうなった。
明らかにMozilla側の実装の方がよかった…。
924:デフォルトの名無しさん
11/12/20 11:02:48.62
このスレで言うことじゃない。
925:デフォルトの名無しさん
11/12/23 14:50:49.73
letやyieldはMozillaの独自実装
断じて先行実装ではない
多分
926:デフォルトの名無しさん
11/12/23 17:49:32.07
先行＝独自です。
ただし、letなんかはharmonyの後でも議論が続いていて入る見込みが大いにあります。
URLﾘﾝｸ(wiki.ecmascript.org)
(function (){ ～ })();とか
new function (){ ～ };とか馬鹿馬鹿しいし。
927:デフォルトの名無しさん
11/12/23 19:13:57.92
本家とはいえ、Mozillaのオラオラ実装っぷりはIEを笑えん
928:デフォルトの名無しさん
11/12/23 19:19:08.58
そうだそうだ
しかるべき組織が策定した仕様から実装しろ！
929:デフォルトの名無しさん
11/12/23 19:41:56.23
そりゃC++をみてから言えよ
イニシアチブを一社がとって進むほうが
結果的にいいものが出来るよ
熟成したら独立組織に移管がよか
930:デフォルトの名無しさん
11/12/23 20:23:08.81
C++はStroustrupが指揮棒握ってるよ。
JavascriptでEichのやらせたharmonyレベルの仕事は常にしてる。
委員会で仕様を策定しているのが原因だと思うのは言語をよく理解できてないから。
931:デフォルトの名無しさん
11/12/23 20:26:15.10
IE6の時代が最もいい時代だったってこった
932:デフォルトの名無しさん
11/12/24 17:49:47.25
MSは前に立つとボロがでるから
後ろからついてく会社
933:デフォルトの名無しさん
11/12/27 05:35:05.97
どうしてECMAScript 4が駄目になったのかつくづく理解できない。
あれさえ通っていればJavaScriptが主流になることに異議はなかった。
2011年になってまだ新しいモジュールの書き方生み出していてどうするんだよ。
URLﾘﾝｸ(waka.hatenablog.com)
このまま本格的に使われるようだと、保守不能なコードが際限なく量産されるぞ。
CoffeeScriptならどうにかなるんかとおもいきや
フォラーム覗いたら、どうすんだよ、どうにもなんねーと揉めてる有様
2005年のスライド↓
「最後に生き残るのはJavaScriptかもな」
URLﾘﾝｸ(eto.com)
完全に的中しているし、確かに生き残ったが、言語としてまるっきり停滞したまま生き残るとか
まして主流にしようとかありえないだろ。
正直、この10年かJavaScript界隈にいて日々バッドノウハウを生み出して喜んでた連中、
言語そのものをどうにかしようとしなかった連中を全員殴ってまわりたいレベル
934:デフォルトの名無しさん
11/12/27 05:45:21.04
Googleが素直にECMAに沿って実装してればなあ。
935:デフォルトの名無しさん
11/12/27 08:16:43.80
>>933
まだ本格的には使ってなくて眺めてる状態だけどひでえ書き方だな
プログラミング界隈じゃよくあるけど妄信的な連中が大声で喚いて何も進まない
936:デフォルトの名無しさん
11/12/27 08:28:59.86
>>933
つ Dart
937:デフォルトの名無しさん
11/12/27 08:44:54.83
Dartは信者も苦笑い。
938:デフォルトの名無しさん
11/12/27 12:01:46.95
4を無理に通してたらバベルの塔再来になってた。
慎重に合意取り付けてくのは当たり前。
今でも非互換性が問題になって、
$(document).readyとかやってるのに。
それから4の機能の殆どは継続審議されてる。
HTML5界隈でも標準化が順調に進んでる。
939:デフォルトの名無しさん
11/12/27 21:33:42.89
URLﾘﾝｸ(blogs.msdn.com)
Math.coshとかMSは何をやってるんだ…
940:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/12/28 00:18:05.15
今更ECMAScript 4を持ちだすやつのFlash臭
942:デフォルトの名無しさん
11/12/28 23:15:02.26
>>926
Mozillaの独自実装とは違った仕様になる可能性大だけどな