のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,432,562人
昨日:no data人
今日:
最近の注目
人気の最安値情報

元スレ+ JavaScript の質問用スレッド vol.116 +

JavaScript覧 / PC版 /
スレッド評価: スレッド評価について
みんなの評価 :
タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter
202 = :

おまえらこりすぎ

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 = :

>>202は余計なvarが必要だが>>199の[][0]は無くなる (範囲外アクセスがちょっと微妙だから…)

204 = :

>>203
C言語ならともかくjavascriptでは微妙でもなんでもないが

205 = :

>>197
漏れは違う型を比較しないから、いつも == を使う
=== だと型を調べたりして、遅くなるのでは?

206 = :

>>205
>=== だと型を調べたりして、遅くなる

それ、逆だって
どっちだろうが型を調べる必要はあるだろ
=== は型が違ったらそこで終わり
== は型が違ったら更に型変換を試みるぶん遅くなる

207 = :

>>197
型が自明でない状況を作らないから == は使わないな
そもそも、=== だと都合が悪い状況がないんだが…

208 = :

ありがとうございます
クロックフォードに従い必ず===にしていたのですが、
よく知られたライブラリのソースなどを見ると==と===を使い分けているようなので
使い分けた方がいいのかな?と思ったのですが
使い分けなくてもいいですよね

209 = :

メリットとしては、==を使っている時は「型が自明である」
===を使っている時は「変数が外部からやってきた」
というサインになり、少し分かりやすい、というものがあると思います

210 = :

>>209
外部からやってきても型チェックや型変換で自明にする
そもそも、自明でないからという理由で何度も内部的に型変換を実行するのは現実的じゃないし、型変換のルールを全て頭に入れるのは面倒だったりする

211 = :

HTMLタグの
data-***
という属性にデータを持たせたりしますが
この方法はブラウザ依存はないのですか?

212 = :

配列の100要素すべてを、memsetのように一括で、
-1に初期化したい

普通は、ループを使うのでしょうが、
こういう感じで、簡単に初期化できますか?

arr.memset(-1);

213 = :

>>211
HTML5をサポートするブラウザならブラウザ依存性はない

217 = :

>>213
ありがとうございます
HTML4だと問題起きますか?

218 = :

全く起きない。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なので
ちょっとやそっとじゃ問題なんか起きやしない。

219 = :

>>212
lodashのtimesを使うのが一番短いかねぇ?

$.map(Array(100), function(){return -1})
$(Array(100)).map(function(){return -1})
_.times(10, function(){return -1}))
_.times(10, i => -1))

アロー関数が使えれば最後の行ぐらいになるが。

220 = :

>>218
ありがとうございました

221 = :

lodashでforってどうやるんだろうと思ってたけど
timesでやるのか~

222 = :

>>217
HTML4では不正な属性値に対する推奨事項は定められているが、規定がないので何の保証もない。
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/appendix/notes.html#h-B.1

>>218
HTML4のそれは規定ではない。
「~の実装では問題ない」という説明は出来ても「HTML4仕様上、問題ない」という説明は適切ではない。

224 = :

lodashでwhileはどうやるんですか?

225 = :

>>224
whileの仕様を完全に満たすものはwhileしかないだろw

つまり質問がおかしい。
(whileを使う?)何かをしたいという目的があって、
それを実現するのにwhileを使うかlodashのメソッドを使うかだろ。

226 = :

おそらく>>221をうけての>>224だろ
仮に>>221がなくても言ってることの大体は理解できるけど

228 = :

言葉そのまま受け取ると理解できないと思う
○○っぽいもの
という風に抽象化して物事を考える能力がないと厳しいかも

229 = :

>>228
具体的なことを言っておいて、他人に抽象化させることを求めるなよ。

質問がおかしいって言ってるだろ?
質問する側が、抽象的な質問をしろって言ってんの。

whileをしたいわけじゃなかったら、
具体的にやりたい事を書けって。

230 = :

今まで何度もあった流れだな

抽象的な質問がある
(1)エスパー回答者が回答する → 解決できなければ質問者は(心理的に)お礼を言って去る → 独自に調べ、レベルアップしてからまた質問する
(2)エスパー回答者が回答しつつ質問返しする → 解決できなければ質問者が質問を追加する → 多くの場合(1)へ
(3)アスペ回答者が回答無しで質問返しをする → 質問者が(初心者なので不十分な)追加質問をする → アスペ回答者が、具体性を求め質問返しをする → 以下ループ
(4)(3)の途中でエスパー回答者乱入 → (1)、(2)へ
(5)放置、回答者現れず → 質問者が自身の質問方法の悪さを自覚 → 質問者去る
(6)良質問なので即解決
大体このパターンで、プラス回答者同士の論争、みたいな
結局のところ、わからない質問があれば放置
というのが質問者にも回答者にも一番良い気がする

231 = :

>>223
なぜHTML4の仕様説明にHTML2仕様を持ってくるのだ?
あなたはその規定の最終文章を読むべき。

「この約束事は拘束力がないことを情報提供者は注意してください。仕様外のマークアップとして、規定外のふるまいをするかもしれません。」

そして、規定だったとしてもSHOULDに実装に対する強制力はない。
MUSTなら準拠しなければならない必然性があるが。
http://www.w3.org/MarkUp/html-spec/html-spec_4.html#SEC4.2

232 = :

>>230
エスパー回答者はともかく、アスペ回答者とは?
質問が曖昧なら質問を返して具体性を求めるのは自然な流れだと思うが(上手く回るかは別として)

233 = :

>>230 はエスパーが多い状況が望ましいと思ってるんかね
エスパーが多い => アスペ質問者は成長しない、普通の質問者もアスペ化
こういう流れになると、お人好しでない普通の回答者は去って行くんじゃないかな

234 = :

あぁ、「わからない質問があれば放置」とあるからそういうわけではないのね。

235 = :

それにしてもアスペ回答者なんて蔑称で表現するところに悪意を感じるけどね

236 = :

放置しても「質問方法の悪さを自覚」してくれる事は稀だろうな

237 = :

”回答への(他回答者の)指摘”を含めると結果的には
的外れ回答や間違い回答なんてほぼないから
わからない質問スルー、エスパー回答+補足質問返し
が一番効率良いと思う
質問者らが中級レベル以上を占めるなら、質問返しのループでも問題ないけど
そもそも中級レベル以上の質問者なら質問もより具体的になるし
やはり放置orエスパーがベストかなと

238 = :

「エスパー回答+質問返し」は質問に答えず、迷走する事が多々ある
本質的には「エスパー回答」と大差ない

「質問返しのみ」がまだましだ
それで揉めるならそこからスルーすれば良い

239 = :

面と向かって会議してるわけじゃないからラグが必ず生じるわけで
質問返ししてる間にエスパー正解答なんてざら

240 = :

そうやってエスパーしてもらった質問者は、次回も要エスパーな質問をするんですけどね。
それって長い目で見れば効率悪いでしょ

241 = :

初心者にありがちな「問題解決のためのワードそのものがわからない」状態
この問題は質問回答の回転率を上げることによって解決します
さらにその過程で回答者のエスパーレベルもアップし易くなりす

デキる初心者さんは自分の質問だけでなく他の質問者の質問にも注目します
そして新たに得たワードの検索結果を頼りに、知識と実践問題解決の経験を増やしていくことでしょう
その場凌ぎスキル目当ての質問者がいたところで何のデメリットもないのです

242 = :

>>231
> なぜHTML4の仕様説明にHTML2仕様を持ってくるのだ?

”昔から" HTMLはそのように決まってるということだ。
HTML2の時代から、そうすべき(SHOULD)となっており、
そうすべきという通りに実装されているから問題が起きないといってるのだ。

244 = :

>>242
> ”昔から" HTMLはそのように決まってるということだ。
それをいうなら HTML2,4 では拘束力のない推奨事項(SHOULD)だ
拘束力のない規定をさもMUSTであるかのように表現するのは好ましくない
(HTML3は調べてないし、未来永劫仕様が変化しないわけではない)

そしてこれは実装依存という事だ
仕様が実装を保証していないのだから「HTML4仕様上、問題ない」とは断言できない
一般的な解は動作要件となる実装で動作検証が必要になる

245 = :

>>244
>拘束力のない推奨事項
RFC2119 のSHOULDはちょっと意味が違うよ

「特別な理由があるなら、規定に従わないことも選択できるが、云々」
言い換えれば、特別な理由がない限り、守ら*なければならない*

246 = :

>>245
特別な理由が仕様に明記されているのだから、RFC2119 規定をそのまま当てはめるのは違うだろう

247 = :

RFC2119 規定はこちら
http://www.asahi-net.or.jp/~bd9y-ktu/htmlrel_f/dtd_f/rfc_f/rfc2119j.html

3. SHOULD この単語乃至は形容詞「勧告(推奨)する "RECOMMENDED"」は特別
な項目を無視するには、特殊な状況での正しい理由があるかもしれませんが、
十分に言外の意味が理解され、別の経緯を選択する前に注意して検討されなけ
ればなりません。

特別な理由があれば無視できるのだからMUSTより優先度が低いことに変わりはない
ブラウザが独自拡張すれば、特別な理由はどうとでもなる
そして、ブラウザの独自拡張は昔から一般的に行われてきた

248 = :

>>246
ああ、HTML4のSHOULDはその仕様の中で、実質的に
RFC2119のSHOULDとは関係ないよ
といった意味と同等の記述があるわけね

249 = :

>>247
>ブラウザが独自拡張すれば、特別な理由はどうとでもなる

どうとでもなるとか、何でもありみたいな言い方は誤解され易いな
少なくともそういった独自拡張には、敢えて仕様と矛盾する道を選ぶなら
それなりに強い根拠や動機が要る、という暗黙の了解はあるんじゃない?

近頃の仕様はだいたい
独自拡張やるならやるで、ベンダプレフィックス使え、とか
メーリングリストに参加して議論しろ
とか、書いてあったりして予防線が張られてるな

250 = :

>>249
XHTML1.0やHTML5では無理だが、HTML4の仕様には矛盾してないだろう
せめて仕様の文言に言及してから指摘してくれ


←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript一覧へ
スレッド評価: スレッド評価について
みんなの評価 :
タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

類似してるかもしれないスレッド


トップメニューへ / →のくす牧場書庫について