私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.114 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
このベンチマークでExtJSが圧倒してるのはなんでなの？
http://jsperf.com/mojo-of-dojo-and-jquery/75
http://jsperf.com/mojo-of-dojo-and-jquery/75
>>845
この件ですが、正規表現でinnerHTMLを置換すればいいだけでした
この件ですが、正規表現でinnerHTMLを置換すればいいだけでした
>>851
function Index() {
var that = this;
$('[id="htmlForm:button1"]')
.click( function () {
that.say();
});
this.count = "aa";
}
Index.prototype.say = function () {
alert(this.count);
};
thatを使う書き方はこう書くのが正しい。
function Index() {
var that = this;
$('[id="htmlForm:button1"]')
.click( function () {
that.say();
});
this.count = "aa";
}
Index.prototype.say = function () {
alert(this.count);
};
thatを使う書き方はこう書くのが正しい。
>>858
まずオレは812ではない。
>>846は見間違えていた。>>846でも構わない。
ただ「スコープが狭いからいい」とは思わないがここは割とどうでもいい。
bindを使う場合とthatを使う場合では本質的に大きな違いがある。
>>790にbindを教えて終わりにするのは「バカはbindでも使ってろ」と言っているようなもの。
bindを使うなら次のコードでもいい。
var say = function () {
alert(this.count);
};
function Index() {
$('[id="htmlForm:button1"]').click(
say.bind(this)
);
this.count = "aa";
}
これより、thatを使った方がオブジェクト指向的には正しいということは理解できるだろう。
まずオレは812ではない。
>>846は見間違えていた。>>846でも構わない。
ただ「スコープが狭いからいい」とは思わないがここは割とどうでもいい。
bindを使う場合とthatを使う場合では本質的に大きな違いがある。
>>790にbindを教えて終わりにするのは「バカはbindでも使ってろ」と言っているようなもの。
bindを使うなら次のコードでもいい。
var say = function () {
alert(this.count);
};
function Index() {
$('[id="htmlForm:button1"]').click(
say.bind(this)
);
this.count = "aa";
}
これより、thatを使った方がオブジェクト指向的には正しいということは理解できるだろう。
「オブジェクト指向的には正しい」は違うな。>>846,857にしてもまだこんな書き方はしないと思う。
俺はオブジェクトをビルドする処理を書いて
メソッドの関数名を特定の名前にしておくと、
親オブジェクトをプロパティーとして持たせるようにしてる
こうするとハンドラの中から本来の親オブジェクトに簡単にアクセスできるので
bindとかする必要がなく便利である
メソッドの関数名を特定の名前にしておくと、
親オブジェクトをプロパティーとして持たせるようにしてる
こうするとハンドラの中から本来の親オブジェクトに簡単にアクセスできるので
bindとかする必要がなく便利である
以前は子オブジェクトが親オブジェクトを分からないなんてアホすぎるだろと憤怒してたけど
JSの仕組み上メソッドは誰の子にでもなれるわけだし、
実際に複数のオブジェクトに所有されてるかもしれないから、仕方ないんだよな
JSの仕組み上メソッドは誰の子にでもなれるわけだし、
実際に複数のオブジェクトに所有されてるかもしれないから、仕方ないんだよな
こういうことね?
var a = {
foo: function () {
return this.val;
},
val: 'a'
};
var b = {
val: 'b'
};
b.foo = a.foo;
console.log(b.foo()); // b
Javaとか知ってると aが表示されんじゃないのって思ってしまうかもね
var a = {
foo: function () {
return this.val;
},
val: 'a'
};
var b = {
val: 'b'
};
b.foo = a.foo;
console.log(b.foo()); // b
Javaとか知ってると aが表示されんじゃないのって思ってしまうかもね
>>860
これで全体を適当に匿名関数でラップしてやればsayがプライベート関数になる
これで全体を適当に匿名関数でラップしてやればsayがプライベート関数になる
http://takanamito.hateblo.jp/entry/2013/04/12/000357
別のファイルからstart()やend()を呼びたいときは
var utilities = new MYAPP.utilities();
utilities.start();
utilities.end();
ってこのブログで書いてあるのですが、
MYAPP.utilitiesてnewなしで呼べるように定義されていますが、
この別のファイルからstart()メソッドやend()メソッドを呼ぶときに
何故newが必要なのでしょうか？また、別のファイルから呼ぶ状況は
どういったことを指しているのでしょうか？
別のファイルからstart()やend()を呼びたいときは
var utilities = new MYAPP.utilities();
utilities.start();
utilities.end();
ってこのブログで書いてあるのですが、
MYAPP.utilitiesてnewなしで呼べるように定義されていますが、
この別のファイルからstart()メソッドやend()メソッドを呼ぶときに
何故newが必要なのでしょうか？また、別のファイルから呼ぶ状況は
どういったことを指しているのでしょうか？
>>868
せいっ！
せいっ！
javascriptの正規表現で質問です。無理かもしれないですが
例えば
var hoge ="12345";
を使ってこれらの文字列の間に半角空白を含めた
var str ="1 2 3 4 5"
を検索した時マッチさせたいのですが変数hogeの中身が分からなかった場合どうやって記述すればいいんでしょうか？
var reg="";
for(var i; i<hoge.length; i++){
reg +=hoge.slice(i,i+1)+' *';
}
var r =new RegExp(reg)
r.exec(str)
とやってもダメでした
例えば
var hoge ="12345";
を使ってこれらの文字列の間に半角空白を含めた
var str ="1 2 3 4 5"
を検索した時マッチさせたいのですが変数hogeの中身が分からなかった場合どうやって記述すればいいんでしょうか？
var reg="";
for(var i; i<hoge.length; i++){
reg +=hoge.slice(i,i+1)+' *';
}
var r =new RegExp(reg)
r.exec(str)
とやってもダメでした
>>871
i が初期化されていないのは誤記としてもそれだと
1 *2 *3 *4 *5 * のように最後に * が付いてしまうぞ
hoge.split('').join(' *') とすれば簡単
目的によっては、検索対象の文字列を加工してから検索する方法も使える
str.replace(/ +/g, '').indexOf(hoge);
i が初期化されていないのは誤記としてもそれだと
1 *2 *3 *4 *5 * のように最後に * が付いてしまうぞ
hoge.split('').join(' *') とすれば簡単
目的によっては、検索対象の文字列を加工してから検索する方法も使える
str.replace(/ +/g, '').indexOf(hoge);
インスタンスを大量に作る場合で
使用率が低いプロパティーを作ると、メモリがもったいない気がします
_hoge
というプロパティーがあり、それがインスタンスのうち1％くらいでしか使われないと、
残り99％は無駄にメモリを専有することになります
使わない時は削除するとか、
prototypeにテーブルのようなものを作って、そこで管理するとか対処法はあるかと思いますが
どうやってますか？
使用率が低いプロパティーを作ると、メモリがもったいない気がします
_hoge
というプロパティーがあり、それがインスタンスのうち1％くらいでしか使われないと、
残り99％は無駄にメモリを専有することになります
使わない時は削除するとか、
prototypeにテーブルのようなものを作って、そこで管理するとか対処法はあるかと思いますが
どうやってますか？
>>874
そのプロパティがどんだけメモリ食ってるか知らんが単なる数字とかだったら気にするだけ無駄
無駄な画像を削除するとかの方が劇的にメモリを節約できる
ただ、デカいプロパティの場合は null で初期化しておいて、適宜 new するのが常套手段
ちなみに null の初期化は必須
undefined のまま放置してるとエラーになったときに未初期化なのかどっかから undefined が
伝搬してきたのか不明になる
そのプロパティがどんだけメモリ食ってるか知らんが単なる数字とかだったら気にするだけ無駄
無駄な画像を削除するとかの方が劇的にメモリを節約できる
ただ、デカいプロパティの場合は null で初期化しておいて、適宜 new するのが常套手段
ちなみに null の初期化は必須
undefined のまま放置してるとエラーになったときに未初期化なのかどっかから undefined が
伝搬してきたのか不明になる
>>784
> 使用率が低いプロパティーを作ると、メモリがもったいない気がします
作る時間のほうが時間のほうがはるかにもったいないです。
1バイトのメモリ = 0.000001 円
あなたが1分働いた給料10円
> 使用率が低いプロパティーを作ると、メモリがもったいない気がします
作る時間のほうが時間のほうがはるかにもったいないです。
1バイトのメモリ = 0.000001 円
あなたが1分働いた給料10円
>>874
コンストラクタ後にプロパティを削除するのは最もやってはいけないこと
オブジェクトがhidden classから外れると逆にメモリを食ってしまう
どうしても必要ないプロパティを付けたくないのならサブクラスを作る
因みにnullで初期化したりしてはいけない
型推論を困惑させ、脱最適化が起こる
初期化しないか、するなら代入する型で初期化すること
型というのはDateならDate、smi穴なしArrayならsmi穴なしArrayでないといけない
脱最適化は１回ならいいが、関数やオブジェクト単位で２回、３回と起こると永久的に最適化されなくなる
コンストラクタ後にプロパティを削除するのは最もやってはいけないこと
オブジェクトがhidden classから外れると逆にメモリを食ってしまう
どうしても必要ないプロパティを付けたくないのならサブクラスを作る
因みにnullで初期化したりしてはいけない
型推論を困惑させ、脱最適化が起こる
初期化しないか、するなら代入する型で初期化すること
型というのはDateならDate、smi穴なしArrayならsmi穴なしArrayでないといけない
脱最適化は１回ならいいが、関数やオブジェクト単位で２回、３回と起こると永久的に最適化されなくなる
今まで恥ずかしくて質問できなかったんですがリファレンスサイトにある
文字列.slice(開始位置 [,終了位置] )
の[]ってどういう意味があるんですか？
文字列.slice(開始位置 [,終了位置] )
の[]ってどういう意味があるんですか？
省略できるという意味だったんですか。ありがとうございます
しかしそれだったら
slice(開始位置 , [終了位置])になりませんか？
なんでコンマを跨いで 開始位置 [ , 終了位置 ] ）になってるんでしょうか？
しかしそれだったら
slice(開始位置 , [終了位置])になりませんか？
なんでコンマを跨いで 開始位置 [ , 終了位置 ] ）になってるんでしょうか？
終了位置だけを省略してコンマを残した
開始位置,
だとエラーになるから。
省略する時にはコンマも同時に省略しないと駄目だよっていう意味
開始位置,
だとエラーになるから。
省略する時にはコンマも同時に省略しないと駄目だよっていう意味
なるほど、カンマだけになったらバグが発生しちゃうのでそこまで考えてくれたんですね
とってもスッキリしました
これからは気持ちよくリファレンスサイト見る事が出来そうです
とってもスッキリしました
これからは気持ちよくリファレンスサイト見る事が出来そうです
あるオブジェクトが何のインスタンスか調べたいとします
instanceofは比較対象の型を決めうちで調べますが、
プロトタイプチェーンにより継承しているすべての型を知りたい時は
どうしたらいいでしょうか
instanceofは比較対象の型を決めうちで調べますが、
プロトタイプチェーンにより継承しているすべての型を知りたい時は
どうしたらいいでしょうか
コンストラクタの中からprototypeのinitializeメソッドを呼ぶ
initializeでプロパティーの初期化をする
これでも最適化されるのでしょうか？
initializeでプロパティーの初期化をする
これでも最適化されるのでしょうか？
される
そのコンストラクタが常に同じ名前、同じ型、同じ順番で初期化すればいい
条件分岐でinitializeを呼んだり呼ばなかったりするのはダメ
そのコンストラクタが常に同じ名前、同じ型、同じ順番で初期化すればいい
条件分岐でinitializeを呼んだり呼ばなかったりするのはダメ
業務アプリでよく使われる、「ファンクションバー」はどのように実装するのがベストですか？
ちなみ、自分がやっている業務アプリでは、F1キーをクリックすると
予めスーパクラスで宣言されていたメソッドが呼び出される仕組みになっています。
public override function f1Check():String { return "メッセージ"; /* 文字列をreturnすると、ダイアログに表示される */ }
public override function f1Click():void { /* 表示されたダイアログでYesをクリックされた時だけ、このメソッドが呼び出される */ }
ちなみ、自分がやっている業務アプリでは、F1キーをクリックすると
予めスーパクラスで宣言されていたメソッドが呼び出される仕組みになっています。
public override function f1Check():String { return "メッセージ"; /* 文字列をreturnすると、ダイアログに表示される */ }
public override function f1Click():void { /* 表示されたダイアログでYesをクリックされた時だけ、このメソッドが呼び出される */ }
>>877
そんな細かい最適化なんかよりデバッグのしやすさの方が100倍重要
undefindが伝搬して原因不明のバグに悩まされるより確実にnullで初期化する事を徹底すべし
勿論オブジェクト以外は0とかもあり得る
そんな細かい最適化なんかよりデバッグのしやすさの方が100倍重要
undefindが伝搬して原因不明のバグに悩まされるより確実にnullで初期化する事を徹底すべし
勿論オブジェクト以外は0とかもあり得る
undefindが伝搬してバグるのはチェックが甘いだけでは？
===で判定したらいいじゃん
===で判定したらいいじゃん
undefindになる一番の原因は未初期化変数のアクセスと配列の範囲外アクセスだと思う
配列も含めて全ての変数をundefined以外の値で初期化しておけば
途中でundefinedを見掛けた時に確実にどこかがバグってると分かる
初期化せずにundefinedのまま放っておく癖がつくと
undefinedを見掛けてもスルーする癖がついてしまうというだけのこと
配列も含めて全ての変数をundefined以外の値で初期化しておけば
途中でundefinedを見掛けた時に確実にどこかがバグってると分かる
初期化せずにundefinedのまま放っておく癖がつくと
undefinedを見掛けてもスルーする癖がついてしまうというだけのこと
>>896
それだと、本来バグとして検出できるものが
検出できなくなるじゃん。
・変数定義するときは必ず代入する（代入したら値はなるべく変更しない）
・配列のアクセスには、forEach系を使う
こうでしょ？
それだと、本来バグとして検出できるものが
検出できなくなるじゃん。
・変数定義するときは必ず代入する（代入したら値はなるべく変更しない）
・配列のアクセスには、forEach系を使う
こうでしょ？
ちなみに、
var a = -1;
if (hoge) a = b[c]; // bの中身は全てundefined以外
だと、cが範囲外アクセスってのがすぐ分かる (cもundefined以外で初期化しておく)
var a = -1;
if (hoge) a = b[c]; // bの中身は全てundefined以外
だと、cが範囲外アクセスってのがすぐ分かる (cもundefined以外で初期化しておく)
入力された文字によってテキストエリアのサイズが変わった時に発生するイベントなんてないですよね？
onsizechangeみたいなのがあればいいんですが。
onkeyupやタイマーでサイズ変更を検出するしかないでしょうか？
onsizechangeみたいなのがあればいいんですが。
onkeyupやタイマーでサイズ変更を検出するしかないでしょうか？
前へ 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.118 + (1002) - [97%] - 2014/8/29 22:30
- + JavaScript の質問用スレッド vol.116 + (1002) - [97%] - 2014/7/1 0:45
- + JavaScript の質問用スレッド vol.115 + (1001) - [97%] - 2014/5/29 16:16
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/3/15 21:30
- + JavaScript の質問用スレッド vol.119 + (1002) - [97%] - 2014/10/3 15:30
- + JavaScript の質問用スレッド vol.112 + (1001) - [97%] - 2013/11/27 16:46
- + JavaScript の質問用スレッド vol.111 + (1001) - [97%] - 2013/11/4 6:00
- + JavaScript の質問用スレッド vol.110 + (1001) - [97%] - 2013/10/13 14:01
- + JavaScript の質問用スレッド vol.134 + (1001) - [97%] - 2018/8/3 23:15
- + JavaScript の質問用スレッド vol.117 + (1009) - [97%] - 2014/8/5 3:30
- + JavaScript の質問用スレッド vol.104 + (1001) - [97%] - 2013/1/28 4:00
- + JavaScript の質問用スレッド vol.124 + (1001) - [97%] - 2015/7/16 1:30
- + JavaScript の質問用スレッド vol.144 + (288) - [97%] - 2020/5/17 20:00
- + JavaScript の質問用スレッド vol.121 + (1001) - [95%] - 2015/1/1 18:30
- + JavaScript の質問用スレッド vol.120 + (1002) - [95%] - 2014/11/8 1:15
- + JavaScript の質問用スレッド vol.122 + (1004) - [95%] - 2015/2/14 4:45
トップメニューへ / →のくす牧場書庫について