私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.116 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
おまえらこりすぎ
var array = [];
array[5] = ['a', 'b', 'c'];
var a;
console.log((a = array[3]) && a[0]); // undefined
console.log((a = array[5]) && a[0]); // "a"
にしとけ
var array = [];
array[5] = ['a', 'b', 'c'];
var a;
console.log((a = array[3]) && a[0]); // undefined
console.log((a = array[5]) && a[0]); // "a"
にしとけ
>>203
C言語ならともかくjavascriptでは微妙でもなんでもないが
C言語ならともかくjavascriptでは微妙でもなんでもないが
ありがとうございます
クロックフォードに従い必ず===にしていたのですが、
よく知られたライブラリのソースなどを見ると==と===を使い分けているようなので
使い分けた方がいいのかな？と思ったのですが
使い分けなくてもいいですよね
クロックフォードに従い必ず===にしていたのですが、
よく知られたライブラリのソースなどを見ると==と===を使い分けているようなので
使い分けた方がいいのかな？と思ったのですが
使い分けなくてもいいですよね
メリットとしては、==を使っている時は「型が自明である」
===を使っている時は「変数が外部からやってきた」
というサインになり、少し分かりやすい、というものがあると思います
===を使っている時は「変数が外部からやってきた」
というサインになり、少し分かりやすい、というものがあると思います
>>209
外部からやってきても型チェックや型変換で自明にする
そもそも、自明でないからという理由で何度も内部的に型変換を実行するのは現実的じゃないし、型変換のルールを全て頭に入れるのは面倒だったりする
外部からやってきても型チェックや型変換で自明にする
そもそも、自明でないからという理由で何度も内部的に型変換を実行するのは現実的じゃないし、型変換のルールを全て頭に入れるのは面倒だったりする
HTMLタグの
data-***
という属性にデータを持たせたりしますが
この方法はブラウザ依存はないのですか？
data-***
という属性にデータを持たせたりしますが
この方法はブラウザ依存はないのですか？
配列の100要素すべてを、memsetのように一括で、
-1に初期化したい
普通は、ループを使うのでしょうが、
こういう感じで、簡単に初期化できますか？
arr.memset(-1);
-1に初期化したい
普通は、ループを使うのでしょうが、
こういう感じで、簡単に初期化できますか？
arr.memset(-1);
>>211
HTML5をサポートするブラウザならブラウザ依存性はない
HTML5をサポートするブラウザならブラウザ依存性はない
>>212
console.log( $.map(Array(100),function(n,i) { return -1; }) );
console.log( $.map(Array(100),function(n,i) { return -1; }) );
or
$(Array(100)).map(function(n,i){return -1;});
$(Array(100)).map(function(n,i){return -1;});
全く起きない。HTMLは当初から未知の属性や未知のタグは
無視すると決められている。
そうでなければ特定のブラウザだけ対応している
属性などというのが作れないことになる。
それにHTML5の仕様は過去のブラウザで問題がでないようにする
という現実主義で作られている。
たとえば、HTML5の<!DOCTYPE html>はIE6でも動く。
<meta charset="utf-8">もIE6で動く。
HTML5以前は本来なら<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">と
書かなければいけないものだった（charsetという属性はない。http-equivという属性しかない）
だがIE6ならびに当時使われていたブラウザが、charset属性を書いても動くという
仕様違反を利用してそれを仕様にした。
このように過去（主にIE6だろう）で問題ないように作られたのがHTML5なので
ちょっとやそっとじゃ問題なんか起きやしない。
無視すると決められている。
そうでなければ特定のブラウザだけ対応している
属性などというのが作れないことになる。
それにHTML5の仕様は過去のブラウザで問題がでないようにする
という現実主義で作られている。
たとえば、HTML5の<!DOCTYPE html>はIE6でも動く。
<meta charset="utf-8">もIE6で動く。
HTML5以前は本来なら<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">と
書かなければいけないものだった（charsetという属性はない。http-equivという属性しかない）
だがIE6ならびに当時使われていたブラウザが、charset属性を書いても動くという
仕様違反を利用してそれを仕様にした。
このように過去（主にIE6だろう）で問題ないように作られたのがHTML5なので
ちょっとやそっとじゃ問題なんか起きやしない。
>>212
lodashのtimesを使うのが一番短いかねぇ？
$.map(Array(100), function(){return -1})
$(Array(100)).map(function(){return -1})
_.times(10, function(){return -1}))
_.times(10, i => -1))
アロー関数が使えれば最後の行ぐらいになるが。
lodashのtimesを使うのが一番短いかねぇ？
$.map(Array(100), function(){return -1})
$(Array(100)).map(function(){return -1})
_.times(10, function(){return -1}))
_.times(10, i => -1))
アロー関数が使えれば最後の行ぐらいになるが。
>>218
ありがとうございました
ありがとうございました
lodashでforってどうやるんだろうと思ってたけど
timesでやるのか～
timesでやるのか～
>>217
HTML4では不正な属性値に対する推奨事項は定められているが、規定がないので何の保証もない。
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/appendix/notes.html#h-B.1
>>218
HTML4のそれは規定ではない。
「～の実装では問題ない」という説明は出来ても「HTML4仕様上、問題ない」という説明は適切ではない。
HTML4では不正な属性値に対する推奨事項は定められているが、規定がないので何の保証もない。
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/appendix/notes.html#h-B.1
>>218
HTML4のそれは規定ではない。
「～の実装では問題ない」という説明は出来ても「HTML4仕様上、問題ない」という説明は適切ではない。
>>224
whileの仕様を完全に満たすものはwhileしかないだろｗ
つまり質問がおかしい。
（whileを使う？）何かをしたいという目的があって、
それを実現するのにwhileを使うかlodashのメソッドを使うかだろ。
whileの仕様を完全に満たすものはwhileしかないだろｗ
つまり質問がおかしい。
（whileを使う？）何かをしたいという目的があって、
それを実現するのにwhileを使うかlodashのメソッドを使うかだろ。
いや、理解できんってｗ
lodashってのはそもそもforやwhileださくね？
そんなの使わずに関数型でいこうやってのが
開発の動機なんだしさ。
lodashってのはそもそもforやwhileださくね？
そんなの使わずに関数型でいこうやってのが
開発の動機なんだしさ。
言葉そのまま受け取ると理解できないと思う
○○っぽいもの
という風に抽象化して物事を考える能力がないと厳しいかも
○○っぽいもの
という風に抽象化して物事を考える能力がないと厳しいかも
>>228
具体的なことを言っておいて、他人に抽象化させることを求めるなよ。
質問がおかしいって言ってるだろ？
質問する側が、抽象的な質問をしろって言ってんの。
whileをしたいわけじゃなかったら、
具体的にやりたい事を書けって。
具体的なことを言っておいて、他人に抽象化させることを求めるなよ。
質問がおかしいって言ってるだろ？
質問する側が、抽象的な質問をしろって言ってんの。
whileをしたいわけじゃなかったら、
具体的にやりたい事を書けって。
今まで何度もあった流れだな
抽象的な質問がある
（１）エスパー回答者が回答する → 解決できなければ質問者は（心理的に）お礼を言って去る → 独自に調べ、レベルアップしてからまた質問する
（２）エスパー回答者が回答しつつ質問返しする → 解決できなければ質問者が質問を追加する → 多くの場合（１）へ
（３）アスペ回答者が回答無しで質問返しをする → 質問者が（初心者なので不十分な）追加質問をする → アスペ回答者が、具体性を求め質問返しをする → 以下ループ
（４）（３）の途中でエスパー回答者乱入 → （１）、（２）へ
（５）放置、回答者現れず → 質問者が自身の質問方法の悪さを自覚 → 質問者去る
（６）良質問なので即解決
大体このパターンで、プラス回答者同士の論争、みたいな
結局のところ、わからない質問があれば放置
というのが質問者にも回答者にも一番良い気がする
抽象的な質問がある
（１）エスパー回答者が回答する → 解決できなければ質問者は（心理的に）お礼を言って去る → 独自に調べ、レベルアップしてからまた質問する
（２）エスパー回答者が回答しつつ質問返しする → 解決できなければ質問者が質問を追加する → 多くの場合（１）へ
（３）アスペ回答者が回答無しで質問返しをする → 質問者が（初心者なので不十分な）追加質問をする → アスペ回答者が、具体性を求め質問返しをする → 以下ループ
（４）（３）の途中でエスパー回答者乱入 → （１）、（２）へ
（５）放置、回答者現れず → 質問者が自身の質問方法の悪さを自覚 → 質問者去る
（６）良質問なので即解決
大体このパターンで、プラス回答者同士の論争、みたいな
結局のところ、わからない質問があれば放置
というのが質問者にも回答者にも一番良い気がする
>>223
なぜHTML4の仕様説明にHTML2仕様を持ってくるのだ？
あなたはその規定の最終文章を読むべき。
「この約束事は拘束力がないことを情報提供者は注意してください。仕様外のマークアップとして、規定外のふるまいをするかもしれません。」
そして、規定だったとしてもSHOULDに実装に対する強制力はない。
MUSTなら準拠しなければならない必然性があるが。
http://www.w3.org/MarkUp/html-spec/html-spec_4.html#SEC4.2
なぜHTML4の仕様説明にHTML2仕様を持ってくるのだ？
あなたはその規定の最終文章を読むべき。
「この約束事は拘束力がないことを情報提供者は注意してください。仕様外のマークアップとして、規定外のふるまいをするかもしれません。」
そして、規定だったとしてもSHOULDに実装に対する強制力はない。
MUSTなら準拠しなければならない必然性があるが。
http://www.w3.org/MarkUp/html-spec/html-spec_4.html#SEC4.2
>>230 はエスパーが多い状況が望ましいと思ってるんかね
エスパーが多い => アスペ質問者は成長しない、普通の質問者もアスペ化
こういう流れになると、お人好しでない普通の回答者は去って行くんじゃないかな
エスパーが多い => アスペ質問者は成長しない、普通の質問者もアスペ化
こういう流れになると、お人好しでない普通の回答者は去って行くんじゃないかな
あぁ、「わからない質問があれば放置」とあるからそういうわけではないのね。
それにしてもアスペ回答者なんて蔑称で表現するところに悪意を感じるけどね
”回答への（他回答者の）指摘”を含めると結果的には
的外れ回答や間違い回答なんてほぼないから
わからない質問スルー、エスパー回答＋補足質問返し
が一番効率良いと思う
質問者らが中級レベル以上を占めるなら、質問返しのループでも問題ないけど
そもそも中級レベル以上の質問者なら質問もより具体的になるし
やはり放置orエスパーがベストかなと
的外れ回答や間違い回答なんてほぼないから
わからない質問スルー、エスパー回答＋補足質問返し
が一番効率良いと思う
質問者らが中級レベル以上を占めるなら、質問返しのループでも問題ないけど
そもそも中級レベル以上の質問者なら質問もより具体的になるし
やはり放置orエスパーがベストかなと
「エスパー回答+質問返し」は質問に答えず、迷走する事が多々ある
本質的には「エスパー回答」と大差ない
「質問返しのみ」がまだましだ
それで揉めるならそこからスルーすれば良い
本質的には「エスパー回答」と大差ない
「質問返しのみ」がまだましだ
それで揉めるならそこからスルーすれば良い
面と向かって会議してるわけじゃないからラグが必ず生じるわけで
質問返ししてる間にエスパー正解答なんてざら
質問返ししてる間にエスパー正解答なんてざら
そうやってエスパーしてもらった質問者は、次回も要エスパーな質問をするんですけどね。
それって長い目で見れば効率悪いでしょ
それって長い目で見れば効率悪いでしょ
初心者にありがちな「問題解決のためのワードそのものがわからない」状態
この問題は質問回答の回転率を上げることによって解決します
さらにその過程で回答者のエスパーレベルもアップし易くなりす
デキる初心者さんは自分の質問だけでなく他の質問者の質問にも注目します
そして新たに得たワードの検索結果を頼りに、知識と実践問題解決の経験を増やしていくことでしょう
その場凌ぎスキル目当ての質問者がいたところで何のデメリットもないのです
この問題は質問回答の回転率を上げることによって解決します
さらにその過程で回答者のエスパーレベルもアップし易くなりす
デキる初心者さんは自分の質問だけでなく他の質問者の質問にも注目します
そして新たに得たワードの検索結果を頼りに、知識と実践問題解決の経験を増やしていくことでしょう
その場凌ぎスキル目当ての質問者がいたところで何のデメリットもないのです
>>231
> なぜHTML4の仕様説明にHTML2仕様を持ってくるのだ？
”昔から" HTMLはそのように決まってるということだ。
HTML2の時代から、そうすべき（SHOULD）となっており、
そうすべきという通りに実装されているから問題が起きないといってるのだ。
> なぜHTML4の仕様説明にHTML2仕様を持ってくるのだ？
”昔から" HTMLはそのように決まってるということだ。
HTML2の時代から、そうすべき（SHOULD）となっており、
そうすべきという通りに実装されているから問題が起きないといってるのだ。
なんで荒れてるんです？
無論lodashでwhileみたいなことをやる、という意味ですよ
無論lodashでwhileみたいなことをやる、という意味ですよ
>>242
> ”昔から" HTMLはそのように決まってるということだ。
それをいうなら HTML2,4 では拘束力のない推奨事項(SHOULD)だ
拘束力のない規定をさもMUSTであるかのように表現するのは好ましくない
(HTML3は調べてないし、未来永劫仕様が変化しないわけではない)
そしてこれは実装依存という事だ
仕様が実装を保証していないのだから「HTML4仕様上、問題ない」とは断言できない
一般的な解は動作要件となる実装で動作検証が必要になる
> ”昔から" HTMLはそのように決まってるということだ。
それをいうなら HTML2,4 では拘束力のない推奨事項(SHOULD)だ
拘束力のない規定をさもMUSTであるかのように表現するのは好ましくない
(HTML3は調べてないし、未来永劫仕様が変化しないわけではない)
そしてこれは実装依存という事だ
仕様が実装を保証していないのだから「HTML4仕様上、問題ない」とは断言できない
一般的な解は動作要件となる実装で動作検証が必要になる
>>244
>拘束力のない推奨事項
RFC2119 のSHOULDはちょっと意味が違うよ
「特別な理由があるなら、規定に従わないことも選択できるが、云々」
言い換えれば、特別な理由がない限り、守ら＊なければならない＊
>拘束力のない推奨事項
RFC2119 のSHOULDはちょっと意味が違うよ
「特別な理由があるなら、規定に従わないことも選択できるが、云々」
言い換えれば、特別な理由がない限り、守ら＊なければならない＊
>>245
特別な理由が仕様に明記されているのだから、RFC2119 規定をそのまま当てはめるのは違うだろう
特別な理由が仕様に明記されているのだから、RFC2119 規定をそのまま当てはめるのは違うだろう
RFC2119 規定はこちら
http://www.asahi-net.or.jp/~bd9y-ktu/htmlrel_f/dtd_f/rfc_f/rfc2119j.html
3. SHOULD この単語乃至は形容詞「勧告（推奨）する "RECOMMENDED"」は特別
な項目を無視するには、特殊な状況での正しい理由があるかもしれませんが、
十分に言外の意味が理解され、別の経緯を選択する前に注意して検討されなけ
ればなりません。
特別な理由があれば無視できるのだからMUSTより優先度が低いことに変わりはない
ブラウザが独自拡張すれば、特別な理由はどうとでもなる
そして、ブラウザの独自拡張は昔から一般的に行われてきた
http://www.asahi-net.or.jp/~bd9y-ktu/htmlrel_f/dtd_f/rfc_f/rfc2119j.html
3. SHOULD この単語乃至は形容詞「勧告（推奨）する "RECOMMENDED"」は特別
な項目を無視するには、特殊な状況での正しい理由があるかもしれませんが、
十分に言外の意味が理解され、別の経緯を選択する前に注意して検討されなけ
ればなりません。
特別な理由があれば無視できるのだからMUSTより優先度が低いことに変わりはない
ブラウザが独自拡張すれば、特別な理由はどうとでもなる
そして、ブラウザの独自拡張は昔から一般的に行われてきた
>>247
>ブラウザが独自拡張すれば、特別な理由はどうとでもなる
どうとでもなるとか、何でもありみたいな言い方は誤解され易いな
少なくともそういった独自拡張には、敢えて仕様と矛盾する道を選ぶなら
それなりに強い根拠や動機が要る、という暗黙の了解はあるんじゃない？
近頃の仕様はだいたい
独自拡張やるならやるで、ベンダプレフィックス使え、とか
メーリングリストに参加して議論しろ
とか、書いてあったりして予防線が張られてるな
>ブラウザが独自拡張すれば、特別な理由はどうとでもなる
どうとでもなるとか、何でもありみたいな言い方は誤解され易いな
少なくともそういった独自拡張には、敢えて仕様と矛盾する道を選ぶなら
それなりに強い根拠や動機が要る、という暗黙の了解はあるんじゃない？
近頃の仕様はだいたい
独自拡張やるならやるで、ベンダプレフィックス使え、とか
メーリングリストに参加して議論しろ
とか、書いてあったりして予防線が張られてるな
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
JavaScript スレッド一覧へ類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/1/25 12:46
- + JavaScript の質問用スレッド vol.110 + (1001) - [97%] - 2013/10/13 14:01
- + JavaScript の質問用スレッド vol.126 + (348) - [97%] - 2023/1/12 17:00
- + JavaScript の質問用スレッド vol.119 + (1002) - [97%] - 2014/10/3 15:30
- + JavaScript の質問用スレッド vol.118 + (1002) - [97%] - 2014/8/29 22:30
- + JavaScript の質問用スレッド vol.117 + (1009) - [97%] - 2014/8/5 3:30
- + JavaScript の質問用スレッド vol.115 + (1001) - [97%] - 2014/5/29 16:16
- + JavaScript の質問用スレッド vol.114 + (1001) - [97%] - 2014/5/3 10:45
- + JavaScript の質問用スレッド vol.112 + (1001) - [97%] - 2013/11/27 16:46
- + JavaScript の質問用スレッド vol.111 + (1001) - [97%] - 2013/11/4 6:00
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/3/15 21:30
- + JavaScript の質問用スレッド vol.136 + (1001) - [97%] - 2019/1/8 11:30
- + JavaScript の質問用スレッド vol.106 + (1001) - [97%] - 2013/7/20 9:30
- + JavaScript の質問用スレッド vol.126 + (952) - [97%] - 2015/11/18 13:15
- + JavaScript の質問用スレッド vol.107 + (1001) - [95%] - 2013/9/7 10:16
- + JavaScript の質問用スレッド vol.121 + (1001) - [95%] - 2015/1/1 18:30
- + JavaScript の質問用スレッド vol.100 + (1001) - [95%] - 2012/6/13 22:46
トップメニューへ / →のくす牧場書庫について