トップページ > プログラム > 2015年12月19日 > WePRjNql

書き込み順位&時間帯一覧

83 位/233 ID中時間01234567891011121314151617181920212223Total
書き込み数0000100000000000000000001



使用した名前一覧書き込んだスレッド一覧
デフォルトの名無しさん
JavaScript情報交換所(プログラミング既習者専用) [無断転載禁止]©2ch.net

書き込みレス一覧

JavaScript情報交換所(プログラミング既習者専用) [無断転載禁止]©2ch.net
28 :デフォルトの名無しさん[sage]:2015/12/19(土) 04:44:14.14 ID:WePRjNql
>>26
問題はArrayが少し変わったオブジェクト程度であること
そしてArrayのメソッドは、ArrayLike(この場合lengthを持つもの)について保証していて最初からそのように作られている
JSにおいて配列の最も基本的な定義はlengthプロパティに要素の長さを記録しているもの程度のことでしかない
当然DOMの配列でも動くし、型付配列でも動く
それなのにわざわざArrayだけでしか動かなくする必要があるのか?

ここがミソで、わざわざArray以外にも対応する、のではなく、わざわざ対応しないようにするのかと考える
Array.isArrayは型付配列すらtrueを返さない
isArrayは配列がどうかのチェックではなく、Arrayかどうかのチェックだ

配列を扱うとする関数でArrayだけに絞るのはJSにおいて必ずしも十分ではないということだ
その関数を作る目的と使われるシチュエーションを考慮しないといけない

>>27
@@toStringTagをお忘れかな?
===の件もそうだな
どうして必要もない制限をわざわざするのか?と思ってしまう
というのは半分ウソで、実際は他の演算子と文字数が違うものを基本で使うのは気持ちが悪いから==を基本で使う
経験上==を基本で使ったからといってバグになるようなことはない
型変換のバグは予想外に同値判定で通ってしまうことよりも、予想外に通らない事のほうが圧倒的に多いのだから


※このページは、『2ちゃんねる』の書き込みを基に自動生成したものです。オリジナルはリンク先の2ちゃんねるの書き込みです。
※このサイトでオリジナルの書き込みについては対応できません。
※何か問題のある場合はメールをしてください。対応します。