次スレは975超えたらネ。

スレの勢いからすると960過ぎくらいでもいいと思う。
どこかの板のスレみたいに950で立てるのは馬鹿だがｗ

>>950
> 配列のサイズが変わったかどうかを突き止めるのは、
> かなり大変でしょ？
まぁ多分大変だろうね
ただ
http://jsperf.com/caching-array-length/4
↑ここでベンチ結果が出てるけど、len代入とarray.lengthそのままでは全く速度は同じだね(青と黄を比較)
ちなみに With caching Part 2 の結果が爆速になってるけど処理内容を変えちゃってるから駄目だろ…

>>953
なんか少し古いバージョンだった…
http://jsperf.com/caching-array-length/25
これが最新だった(結果は一緒だけど)

>>934話の流れを見て欲しい。あくまで２段階コンストラクトを行うとき、及び内部的なプロパティの話をしている。
この場合の未初期化というのは継承可能、共有可能な第一コンストラクタ、つまり@@createやそれに当たる関数に処理されて、
そのオブジェクトがそのクラスのインスタンスたる最低限の処理、つまり内部プロパティに当たるものだったり、
プロキシの設定を済ませてはいるが、メソッドでの処理に必要な情報の多くを決定＝初期化されていない状態を指している。

コンストラクタを「作る」フェイズと「初期化する」フェイズにキッチリ分け、両方を意識することでコンストラクタ≒クラスを継承、再利用しやすくなる。
ES6でもそれ＝@@createがあるからネイティブクラスの継承が容易にできるようになっている。
例えば　class MyArray extends Array {};;; obj = new MyArray(...arg) は obj = MyArray.call(MyArray[@@create]() ,...arg) と大体等しく、
まず作る段階でMyArray.__proto__[@@create]、つまりArray[@@create]がthisをMyArrayとして呼ばれて適切な処理を受けることが出来る。
そして続けてのconstructorもデフォルト処理のsuper(...arg)が適切に効く。

コンストラクタを二段階にするのは他にも理由がある。それは安全性のため。
コンストラクタはthisを初期化するものだが、それだとClass.call(tekitou)みたいな使い方ができてしまう。
これを許すとProxy性を持たないArrayだったり、「規格外の正当なインスタンス」が存在し得るので各所でのチェックが余分に必要となったりといいことがない。
だから、ClassのconstructorのthisはそのClassの未初期化のインスタンスのみを受け付けるようにする。

しかしESにはクラスは存在せず、インスタンスとその作成元を保証してくれるような静的な繋がりもないので、インスタンスかどうかの判断が問題になる。
ここでES6内部仕様に習うと、そのクラスの代表的な内部プロパティの有無で判断する。
そして内部プロパティを持っていても、初期化済みのインスタンスを再初期化する事のないように、内部プロパティがundefinedかどうかで初期化済みを確かめる。
逆にメソッドでは、未初期化のインスタンスがかけられないように、初期化済みを確かめる。

つまり安全性のため、内部プロパティを設定、確保する段階がコンストラクタより前に必要になる。
そうすることで最小限のコードでクラスの安全性と発展性を両立させることができる。
プロトタイプベースで内部的にダックタイピングを利用するしかなくても、厳正なクラスを提供することが出来る。

そして厳正なクラスにおいて、プロパティとデータをごっちゃにすることはない。
原則プロパティとはアクセサであって、ネイティブのクラスでもメソッドでオブジェクトの外部プロパティを直接利用するというものはほぼ無い。
必ずアクセサ経由で内部プロパティの変更、参照を伴うものになっていて、メソッドは内部プロパティを利用するようになっている。
そして原則内部プロパティがundefinedのときは即エラーにする。nullは0と同じような列記とした初期化済みの値で、未初期化のような意味は持たない。

何回も使うものはあらかじめ変数にキャッシュしておくっていうのが
プログラミングにおける合理性なわけじゃん
万が一謎の最適化のせいでその方が遅くなるとしたら、
それは最適化の方が間違っているんだから
プログラマーが気にする必要はない
間違ったものはいずれ修正されていくから。
最適化を気にして非合理なコードを書くのは本末転倒すぎる。
よってC級プログラマー。

最適化厨は最適化にかかるコストを頭に入れてないよね
くそダサいコードを最適化するのもコストがかかるんですけど？

筋の悪い最適化に合わせて筋の悪いコードを書いて
それが時間の経過と共に非最適化していくと目も当てられない
プログラマーはひたすら筋のいいコードを書くことを心がけてさえいればいい

普通はobj.propを一々明示的にキャッシュしたりしないのが筋がいいが、配列のlengthだけは特別
配列のlengthは知っての通りプロパティでもなく、アクセサでもなく、プロキシのようなオブジェクトのハックによって実現されてる
特殊中の特殊で一般的なキャッシュ最適化の話はできない
どれだけ処理系が配列の実装に特別な工夫を凝らしてるのかという話になる
そこを把握して期待するのは余りに重いので、プロキシが気持ち悪ければキャッシュしてもいい

それは筋がいいのではなく単なる怠慢
ローカル変数が一番速いという真理は変わらない

「そうした方が速くなるのが当たり前」なことをするのが筋のいいプログラミング
わざわざローカル変数に入れなくても最適化してくれる環境もあるかもしれないが、
そんな働くか働かないか分からない最適化に期待するのは筋がいいとは言えない

> 「そうした方が速くなるのが当たり前」なことをするのが筋のいいプログラミング

違うよ。

最優先に考えるのが開発コストを下げること。
速度に関して言えば効果が高い所のみ手を入れるのが筋のいいプログラミング

だからライブラリを使うんだろう？
ライブラリを使うと関数呼び出しが増えるからたいてい遅くなる。
それでも使うのは開発コストを下げるため。

>>962
多くの開発者が考える「そうした方が速くなるのが当たり前」は当てにならないと言う当たり前の常識を知らない時点で(ry

thickboxの最新版なんですが、
子を閉じたときに親がリロードするのを止めるにはどこをどうしたらよろしいでしょうか？
ご教示お願いいたします

>>963
開発コストを最優先した筋のいいプログラミングなんてないから
それは安いプログラミング
それ以上でも以下でもない

>>964
迷信に頼るのではなく、自明の事実に基づくべきだと言っているんだよ
カスが

>>955,956
俺は934だが単なる開発ポリシーの話しをしてるのに、あんたは随分規格に詳しいようだが
ES6のclassの継承の話しをされても、実装されてないもんは全く実感出来んしよう分からん…

ES6のclassの継承になんらかの問題がありそうな主張は分かったんで、実装されたら
また気にしてみるよ

>>960
> 普通はobj.propを一々明示的にキャッシュしたりしないのが筋がいいが、配列のlengthだけは特別
Float32Array とかはlengthは変更不可(pushとかも不可)だから、その前提は常に正しいとは言えない

>>966
開発コストって単に人件費をムリクリ抑える事をいうのでなければ、
開発効率を追求する事は最優先だと思うよ

開発効率を追求して開発コストを抑える事が出来れば筋のいいプログラミングと言える

>>967
おまえが経験浅いのは分かったから、もう黙ってろよw

論ずるなら、その主張の根拠となるコード例の一つでも出せばいいのに

ローカル変数に代入するというごく普通のテクニックまで否定し出してびびるわw
まぁ俺には関係ないからいいけど

いつの間にか使わなくなったプロパティーを見つけたいと思います
プロパティー名を文字列として検索してどこにもなければ使われていないと判別できると思います
そういうことをやるプログラムなどはありませんか？

>>968
ES6に限った話じゃないよ。ES6で大々的に摂り入れて成功してる話を交えただけ。
ES5で全部を真似するのは難しいけど、考え方、ポリシーは摂り入れられる。
話が膨らんだがnullの件については>>956の最後の段落が言いたいこと。

口だけで筋のいいとか言われてもわからんから、サンプル見せてくれよ

できれば、悪い例とどうしたら筋が良くなるって解説つきで

>>973
ローカル変数に代入するのは
開発しやすくするためで
速度のためじゃないんだよｗ

>>973
論点ズレてるなあ。
そんなレスしてるから経験浅いとか言われちゃうんだよ。

いや俺は変な2chねらーの意見よりも
ハイパフォーマンスJavaScriptの著者のニコラスを信用するからw
経験ワロスww

本に書いてあることは全て正しいと思ってるタイプか
専門書で間違ったこと一切書いてない本なんてそうそうないぞ

俺も本の正規表現が間違ってて数日悩んだ事があったから
軸となる本と、ネットで情報収集、ココで質問するといい

学校の教科書だって初版だと訂正箇所みたいなの沢山出てくるんだから

著者を信用してるって言うのと、本に書いてあることを信用してるっていうのはまったく別次元話だろｗ

教科書で自分のｽｷﾙを強化しょう

いったん変数に代入するのは、古いPC・ブラウザ向けの対策。
新しいものは、変数が少し増えても、影響は受けないだろ

それに、Webサイトはプログラムなどと違って、
1回しか見ないことも多いので、
時間をかけて最適化して元が取れるのか、という観点もある

それより、Mathの関数を何百回も呼ぶので、
変数に代入して使っているんだが、これは正しいのか？
>>950
// 乱数を発生させる。少数点以下を切り捨てる
var fRnd = Math.random, fFlo = Math.floor;
fFlo(fRnd() * 100);

それと、配列のアクセスには、forEach系を使う、
って誰かが書いていたけど、forの方が速いのじゃ？

>>985
>>950ではないが…。
- Math.random をローカル変数にキャッシュするのは手法として間違ってない。
- 一般に関数呼び出しは遅いので forEach より for が速い。

>>987
Math.random はグローバル関数であり、ローカル関数よりも遅い(スコープチェーン)
更にプロパティアクセス演算子も1回しか使用しなくて済む

例えば、MathのアドレスがA番地として、
randomのアドレスがBとして、

var p = Math.random;
とすると、pにはB番地が入る？

でも、変数に代入せず、Math.randomのまま使うと、
毎回、A→Bの間接参照が行われるの？
なぜインタプリタは、Bを変数に代入して使わないのか？

>>990
>>989でも説明したが、スコープチェーン
プロパティアクセスが遅い理由はプロトタイプチェーン

当然してる
ただMathに変更がないことを確認するオーバーヘッドがある
それとただのキャッシュだけではなくて、random内の処理が埋め込まれて、それからさらに最適化がされる
その辺でより最適化を望むならES7のRelationshipsに期待するといい
http://wiki.ecmascript.org/doku.php?id=strawman:relationships
これは確認がいらない、というか、処理系の代わりに、責任をset/get関数側が負う設計
もしそれを守らなかったり、設計ミスをすると、最適化/非最適化で結果が変わるというJSには珍しいアンセーフな代物
その代わり最高のパフォーマンスが出る

やっとキャッシュは有効というまともな話になったか
キャッシュ否定厨はキャッシュに親でも殺されたのかよw

>>988
>プロキシ、ゲッター、スロットへのアクセスだから
結局、"a.b"と、ドットが付いていたら、
何でも変数に代入した方がいいのかな？

Math.randomまで代入するのは、やりすぎのような気もします
変数が多くなって、プログラムがわかりにくくなる

プロキシ、ゲッター、スロットの中で、
どれを変数に代入すべきでしょうか？

長時間、お付き合いありがとう
古いPC・ブラウザのことを考えると、
どうしてもインタプリタが最適化しやすい、
プログラミングを考えてしまいます

chromeのconsole.timeの最小単位は1msなのでしょうか？
小数点以下が0以外になったのを見たことがありません

textareaにある文字をそのまま$(textarea).val()で取得してdata-unk=""の中に入れちゃおうと思うんですが
これってエスケープとか必要ですか？

dom要素へのidの設定はsetAttributeを使うのとidプロパティへの代入と
どっちがいいんですか？

変数に代入って言葉そろそろやめませんか

じゃあいい言葉考えろよ