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

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

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

851 = :

やれやれ

852 = :

やれやれに逃げたw
技術的論争で技術以外のところに逃げ込む人って・・

853 = :

はいはい

854 = :

m9(^Д^)ﾌﾟｷﾞｬｰ

855 = :

>>849
polyfillも知らないとは恥ずかしい奴

856 = :

未宣言変数処理なんぞがあり得ると思ってる奴は
巻き上げを知らないんだろうな

857 = :

>>856
それ関係ない

858 = :

>>855
polyfillは
if (!Map) {
みたいなので事足りるけど、これは Map が存在した場合に、0やnullでない事が
分かってるから否定で判定出来るだけで、厳密に判定する場合はやっぱりtypeofを使う方がいい

859 = :

未定義が存在すること自体おかしい、という根拠のない主観はどうでもいい

860 = :

>>859
この文脈で根拠のない主観って日本語が出てくるのが謎である
変数定義もしないで使ったらエラー出るからtypeofを応急措置的に使うのはバグの元だからやめるべき
しっかり変数宣言を行なえばいいだけ
var a;
console.log(a === void(0));

861 = :

typeof XMLHttpRequest とか、既存オブジェクトのチェックで普通に使うんだがな
経験が浅いんだろうな

862 = :

経験というか…

863 = :

ライブラリに依存していてクロスブラウザ用コードを書いたことがないんだろう

864 = :

>>861
それvoid(0)でもいいわけだが

865 = :

クロスブラウザ対応するにはtypeofを使わなければいけないとか思ってるほうが経験が浅いと思うがね

866 = :

>>864
具体的にはどう書く？

867 = :

結局typeof厨はこれ以上戦えなくなってきたから話をずらそうとしてるのが見えてきた

868 = :

そろそろ論破する奴が出てきそう

869 = :

XMLHttpRequest === void(0) と書くのが目に浮かぶようだ
どうせ試してないんだろうな

870 = :

答えられないから話をずらしてきたのか

871 = :

undefinedの判定にtypeofもvoid(0)も使えるけど
>>861と>>869は何の話をしてるんだ？

872 = :

>>842のように用途に応じて使い分ければ良いだけ
typeof房とか排除する方針を持っている奴は信用ならん

873 = :

確かにXMLHttpRequestの有無はtypeofが妥当かな
未宣言チェックはtypeof
undefinedチェックは===undefinedでやるのがベストってことだな
はい論破

874 = :

>>871
おまえこそ何の話をしているんだ？
>>849,858がどういう意味で使っているのか理解してないのか？
undefined値の判定の話はしてない
ReferenceError を判定するのに typeof 演算子しか使えないという話だろ

875 = :

>>873
あれ、まともなこと言ってる
偽物だな

876 = :

ふつうにwindowのプロパティ見ればいいだけやん

877 = :

>>876
window依存がある上、[[Call]] 持ってなかったら call できない

878 = :

>>860は微妙に話しがずれてんだよな…
「typeofを応急措置的に」って…だから自分が書いたコードのチェックの話しをしてんじゃねーんだよ！
アホだなー

879 = :

typeof a === 'undefined' がGoogle Closure Compilerで
ミニファイ出来ないってのは初めて知ったな。

普通にundefinedと比較したほうがメリット多いんじゃね？

882 = :

>>879
メリット多いというが、具体的には？

883 = :

>>882
ミニファイ出来る。
タイプ数が短い
lint系ツールとの相性が良い
可読性が高い。
未定義の場合にエラーになってくれる。

今まで出てるのはこんなところだね。

885 = :

>>883
> 未定義の場合にエラーになってくれる。
さらっと、まだ言ってんだな

普通にコーディングしてて未定義のエラーになった→これは普通→コードを修正する
未定義かundefinedのチェックをする→未定義の場合にエラーなってくれる？？？

そんなに未定義の場合にエラーにしたいんだったら、
if (!foobar) { または if (foobar) {
で十分、ちゃんとエラーになるし短かい

わざわざ、typeof a === 'undefined' をする意味が分かってないんだな

886 = :

>>884
大文字小文字を区別しないで検索すればいい話でしょ
javascriptというかデータベースの話

887 = :

>>886
えっ？
という事はAjax上でデータベースに都度問い合わせると言うことですか？

自分はサーバサイドでまずデータベースへ問い合わせし、出てきた結果をそのままJSON化しファイルに格納
それをAjaxにて処理毎にそのファイルに問い合わせオートコンプリートと考えてたんですが
その場合大文字のアルファベットしか取得できません

勿論サーバサイド側でJSONファイルを作成時に大文字を小文字化したものも格納すれば良いのかもしれませんが

クライアントサイド側で出来ると思ってたんですがサーバサイド側で処理すべきなんですかね

888 = :

＞えっ？
＞という事はAjax上でデータベースに都度問い合わせると言うことですか？

後出しかよ
じゃあ入力内容を大文字にすればいいだろ

889 = :

>>883
> lint系ツールとの相性が良い
typeofだとなぜ相性が悪いのか不明
もう少し、具体的に

> 可読性が高い。
読者の問題
どちらもたいして変わらない

891 = :

newでインスタンス生成するのは古いやり方で
これからは廃れていくのでしょうか？

892 = :

リテラルで生成する方法はあるけど、コンストラクタからインスタンスを生成するのに
new以外の方法があるわけがない

C++はnewをプライベートにする事は出来るけど、JavaScriptでは出来ないからnewは呼ばせて
内部でどうにかするのがいいだろうね(シングルトンとか)

JavaScriptパターンにその辺の事は書いてある

893 = :

コンストラクタを使わなくてもObject.createでオブジェクト生成できるし、
JavaScriptの本でもそっちを新しい方法として紹介しています
新しい方法が出てきたからにはもう古い方法はなくなっていくのでは？

894 = :

あー、Object.create()があったか (まぁ内部でnewを呼んでるけど)

もうこの辺は考え方の違いになるけど、Object.create()は他の言語のクラスや継承の概念とは
違うJavaScript特有のオブジェクト作成方法(のラッパー)だから、積極的に使わなくていいと思ってる

ES6になればclassも使えるようになるし、それまではclassをエミュレートした
何らかの(または自作の)クラスシステムを使ってればいいと思う

つうか、newが古い新しいにマジレスしてたら、また変な事になりそうなんでこの辺でやめとく…

895 = :

内部でnewを呼んでいるとは？
変な負け惜しみにしか聞こえませんが気のせいでしょうか？
Object.createは、
JSのnewが変態的で分かりにくいという反省から
JSらしいオブジェクト生成に回帰した正統進化だと思いますが？

896 = :

http://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Object/create
これのPolyfill見ればいいだろ
第2引数の設定が省かれてるけど、動作的には全く一緒

897 = :

>>893
インスタンスの初期化処理をどうするかって話になるんだよね
Object.createしたあと必ずinitメソッドを呼ぶみたいな決まり事を作るくらいなら、
コンストラクタでいいじゃんって

結局みんなクラスベースが好きで、プロトタイプなんて隠ぺいしてほしくて、
altJSがわんさか溢れ、ES6にはclass syntaxが入っちゃう

898 = :

>>896
polyfillはnewしかないバージョンのためのものなんだから
newで代替させるのは当たり前だろ
そこから内部的にnewしてるという結論にはならねーよ
まさかの珍ロジックでびびったわ

899 = :

プロトタイプベースにおいてはプロトタイプチェーンの伸長だけが
いわば原現象として存在している
newはプロトタイプチェーンの伸長をクラスベース風に記述可能にしたシンタックスシュガーでしかない
従って内部的にnewする、という言い方は成り立たない
はい論破

900 = :

>>898>>899
やってること一緒でしょ
実際にどう実装されてるかソース確認してみるよ
JavaScriptのAPIなんてほとんどJavaScriptで実装されてるわけだし


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

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

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