>>798
JSLintについて知らなかったんですよね？
だから >>789 で解釈が違うのだろうと推察したのです
そして私は始終一貫してエラーを吐く「理由」を質問していたハズですが、
そのレスは解答の方向性が全く違っていたのでドヤ顔で高らかに「違います」と宣告させていただきました
そのように解釈されず大変残念です

>>800
すみません、ありがとうございます
ちなみに私のレスは >>781 >>785 >>789 >>797 で、>>785 の時点でこの問題は解決しております

キチガイが湧いてるなｗ

こうして間違った解釈が広まるのは残念な限りだ

781が馬鹿すぎて笑えない

コミュ力があれば起きないような誤解と不快感を招いてるな。

varなんか使うからいけないのだ
letが標準化されればいいのに

またeval厨か

ループ内で関数作ると外で作れば一個で済むのに、全く同じような定義を何個も作って無駄なんじゃねえのみたいなことなんじゃないの

本人が説明してるんだからおれおれ解釈の余地はない　上：ビデオ　下：スライド(73ページ)
http://developer.yahoo.com/yui/theater/video.php?v=crockonjs-3
http://www.slideshare.net/douglascrockford/crockford-on-javascript-act-iii-function-the-ultimate

補足すると、上に出てるように無駄っていうのと後は紛らわしいから

誤解が起こるのは、紛らわしいっていうのがクロージャが必要な場面のことだからだと思うけど
でもその場合でも同じで「関数を返す関数」自体を外に置こうっていう話

こんにちは。
初めてJSLintを使ってみましたが
if (hoge == 0)
if (hoge == true)
というように書いた行で、それぞれ以下のようなエラーが出ました。

Use '===' to compare with '0'.
Use '===' to compare with 'true'.

== では好ましくないということなのでしょうか。
何故 === を使えといちいち強要されるのか理由が理解できません。
教えてください。

0==="0" false
0=="0" true

0 == false -> true
0 === false -> false

こういう違いがある
他にも
'' == false -> true
'' === false -> false

とかね
組み込み関数にも0をかえしたり空白を返すものがあったはず（忘れた
そういうのでの誤った判断をしないためにって感じかな
型をも含めた厳密な比較をしましょうって事です

"自分で"JSLintを使っといて、理由も調べないでいちいち強要されるとか馬鹿じゃねーの

a が false , 0 , -1 , "" , "0" , "-1" の時にtrue

if( Number(a) < 1 )

>>815
そのJSLintの結果はエラーっていうよりお知らせ・注意くらいに思ったほうがいいね。
挙動を理解してるなら問題ない。

>>797
端から見ている私には >>781 が >>785 で解決できているように見えない。
>>781 と同じ結果を >>785 で得られていないから。

あなたが解決できたのは実際にやりたいことが >>781 ではなく別にあってそれが >>785 で解決できただけ。
そしてあなたの疑問である「どういう理由があってこのエラーが出るのでしょうか」の解が >>785 で出ているようには見えない。

だから、皆口を揃えて「そんな書いてないことなんかわかんねーよ」といっているわけです。
JSLint云々の問題ではなく、質問の仕方が悪いとしかいえない。

・ブロックスコープ云々と「Don't make functions within a loop.」は全く関係がない。
・JSLint はCrockford氏が信じる Good Parts でないコードに警告を出す。よって、ECMAScript文法に準拠しているか否かは全く関係ない。

「Don't make functions within a loop.」のメッセージを出す理由はわからないが、少なくともあなたの論拠はちぐはぐとしか思えない。

>>815
そういう場合は明示的に型変換してやればいい。
Number('0') === 0

=== and !== Operators.
It is almost always better to use the === and !== operators. The == and != operators do type coercion. In particular, do not use == to compare against falsy values.
http://javascript.crockford.com/code.html

>>818
> ・JSLint はCrockford氏が信じる Good Parts でないコードに警告を出す。よって、ECMAScript文法に準拠しているか否かは全く関係ない。
これは言い過ぎた。
ECMAScript に準拠していることが前提にあり、その上で独自の解釈をすると認識していいと思う。
例えば、var num = parseInt(08); で「Missing radix parameter.」のエラーを返す。

>>819
全部そう書き換える必要があるってことですか？

>>822
間違いが起こりにくいコーディングのテクニックとして、
文字列になる可能性がある数値は、きちんと数値に変換してから扱う。
parseInt(num)してから、if (num === 0)って感じで。

parseInt("0hoge")とかに注意だな

parseInt と Number の違い
http://ideone.com/x7oVl

parseInt の注意すべき点として、

・第二引数を省略すると 8進数, 16進数として扱う場合がある。(JSLintでは「Missing radix parameter.」のエラーを返します)
・数値は前方一致で検索される (後方に数値以外の文字があったとしてもエラーにならない)

があるかと。parseFloat には前者の性質がないですね。

>>822
必要なら、全て型変換を行った方がいいと思います。
同じ値を使い回すなら始めにNumber型に変換するとか。

function foo (num) {
　num = Number(num);
　if (num === 0) {
　　// 処理1
　} else {
　　// 処理2
　}
}

＞・第二引数を省略すると 8進数, 16進数として扱う場合がある
この動作は誰が得するのか分からん。
ECMAScript3ですら非推奨なのに、
ブラウザの実装が5に準拠するのはいったいいつになるんだ。

>第二引数を省略すると 8進数, 16進数として扱う場合がある。
これってどういうコード（環境？）だと再現するのかな。

先頭が"0x"または"0X"から始まってたら16進数、"0"から始まってたら8進数
たとえばparseInt("018")はまず8進数と見なされ、
末尾の"8"は8進数では使えないゴミとして無視されるので1になる
これJSの基本な

追記。
この動作はECMAScript3では非推奨。5では明確に禁止。

あーそういうことか、サンクス。
16進数はたまに使うけど、0x付きだし間違えることはないかな。
8進数の場合は、日付データとかを数値化するときに危ないね。しかし8進数の使い道がわからんw

Javascriptで並列処理、複数スレッドを立てる事ができるのでしょうか？

Workerでぐぐれ

マウス座標を取得するメソッドって種類ありすぎじゃないですか
なんで一つ、二つに統一しないんですか

その違いを言ってみろ

>>833
マウス座標を取得するメソッドなんてあったかな。
event.screenX はプロパティだし、いろいろプロパティがあっても役目が違うから何とも。

>>833
そのメソッドの名前は？

>>818
最初から何度も言うように結果を求めてたわけではなく理由を求めてたわけです

>>785での解答としては、Don't make functions within a loop. のメッセージは
他の主な言語と違ってJSがブロックスコープをサポートしていないが故に、
書いた通りのクロージャしか作れずバグの温床になるから
(>>809-810 でも説明して頂いている通り無駄があるという問題もあるようですが、こちらの方がより問題だと感じます)

なので、
＞・ブロックスコープ云々と「Don't make functions within a loop.」は全く関係がない。
これは否定させていただきたいと思います

>>781 のコードでは不具合が起こらなかったので、なぜこのメッセージが出るのかを模索したところ、
>>785 のような事例で意図とは違う動作をする可能性を見つけたので、問題となるコードを例示し解決済みとしたわけです

つまりJSLintの作者よりオレオレ解釈が正しいtという事を言いたいのだな？

>>838
どこらへん？
今ビデオ見てるけど該当箇所がよくわからん

シークバー10分の9くらいの位置だな。最後のほう

>>837
「どこかに原因があるはずだ -> >>785で不具合になった -> そうだったのか」ということか。
仮にそうだとしても、>>785 が原因と結論づけるのは強引なのでは？

function foo () {
　var a = new Array(5);
　for (var i = 0, l = a.length; i < l; i++) {
　　a[i] = (function (i) { return function () { alert(i); }; })(i);
　}
}

このコードは JSLint でエラーは出るが、正しく動く。
for文で function を代入してエラーが出るのは書き方が間違っているだけだ。
この点は >>786 で指定されていると思うのだが、試してないのだろうか？
間違った書き方をしているケースをとりあげて「for文で function を代入すべきではない」と主張するのはおかしいと思うのだが…。

あなたの主張は「Crockford氏は >809-810 と説明されていますが、私は別の問題を発見しました。それが >>785 です。」と読める。
それは JSLint がエラーを返す理由ではないよ。エラーを返す理由は JSLint 作者であるCrockford氏がよくご存じのはず。
私にはCrockford氏の説明を疑うだけの正当性が >>785 からは読み取れなかった。

以下、>809 の「Crockford On JavaScript: Act III: Function the Ultimate」より。

--- (P73) ---
Don't make functions in a loop.
- It can be wasteful because a new function object is a created on every iteration.
- It can be confusing because the new function closes over the loop's variables, not over their current values.
-------------

--- (P74) ---
Creating event handlers in a loop

for (i ...) {
　div_id = divs[i].id;
　divs[i].onclick = function () {
　　alert(div_id);
　};
}
----
function make_handler (div_id) {
　return function () {
　　alert(div_id);
　}
}
for (i ...) {
　div_id = divs[i].id;
　divs[i].onclick = make_handler(div_id);
}
-------------

>>838
thx 見つけました

>>838
一番最初に取り上げられてる具体例は 「Creating event handlers in a loop」 ですね
で、この問題はクロージャから起こる混乱と明言してるわけですが

>>841
確かに類推の部分はありましたが、ビデオを紹介して頂いたおかげで確証に変わりました
ありがとうございます

>>842
Crockford氏の主張する「新しく関数オブジェクトを生成するのが無駄になるから」という理由が良くわかりません。
P74 下段のコードでも新しく関数オブジェクトを生成していることに代わりはないはずで、>786 と原理は変わらないと思うのですが…。
無名関数で関数オブジェクトを生成するか名前付き関数で関数オブジェクトを生成するか、の違いでしかありません。

もし、本当に関数オブジェクトの数を減らしたかったのならば、

document.addEventListener('click', function () { ; }, false);

と一つだけ定義すれば良かったんじゃないかと。(click はバブリングします)

>>841
ちなみに最初に例示したコードでは動作には何も問題がないですが、ループ内でクロージャ作成関数を呼ぶように修正すると無駄が生じます
誤解されているようですが、私は原因さえはっきりと把握できているならJSLintでエラーが出ようが気にしないというスタンスです

>>844
ループのたびに無名関数を返す無名関数を作成するから無駄となるのだと思います

>>844
クロージャはもちろんループぶん作られるわけだけど
クロージャを返す関数自体をループぶん作ってるじゃん

>>832
ありがと

>>846-847
ありがとうございます。合点がいきました。

しかし、これはかなり特殊なケースですね。
ループの度に変化する変数に参照する状況限定で再現される不具合なので、この警告を無視できるケースはかなりありそう。

>>844
P74 下段のコードは、上段のコード(クロージャの失敗例)に対する正しい例というだけでしょ。
ループの中で関数を生成さえしなければ、混乱を起こさず、間違いを防止しやすい、と。
「新しく関数オブジェクトを生成するのは無駄」というのは、また別のケースでしょう。