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

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

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

    101 = :

    >>99
    現象が再現できる形でコードを掲示してください。
    ideoneは違う、jsfiddleは違う、あれもこれも違うでは現象を再現できません。

    102 = :

    確かにグローバルオブジェクトを渡すのだから、グローバルオブジェクトが特定できる形にしないと意味がないな。
    HTMLがない条件ではグローバルオブジェクトは如何様にも変化する。

    104 = 91 :

    再現してもらいやすいようにHTMLファイルにして書き直しました
    http://ideone.com/CQA3e3

    105 = :

    >>103
    なるほど
    多分グローバルオブジェクトとフレームが繋がっていて
    走査中に跨ごうとしてしまったんだと思います
    ローカルの何もないHTML上で確認していたので気づきませんでした
    ご指摘ありがとうございます

    106 = :

    >>105
    なるほどじゃねえよ糞野郎

    107 = :

    >>104
    ざっとしか読んでませんが、気がついた点がいくつか。
    ・isObject でObject型を完全に判定できていません。typeof obj === 'hoge' や typeof obj === 'function' もObject型です。
    ・JSONは function を許容しませんので function だった場合に文字列化する処理が必要です。
    ・byXJSON(xjson, nativeFunc) の nativeFuncの処理がありません。そもそも、"netive code" なfunctionに限定する意味は何でしょう？

    108 = :

    >>105
    window にパスするように作るなら当然、frameも考慮する必要がありますが、そこは考慮しなくて良いのでしょうか。
    そもそも、どこまで機能するものを求めているのか、要求仕様が見えてきません。
    frameを考慮しなくて良いなら、window 以外の引数をサンプルにすべきだと思いますが。

    109 = 91 :

    jsfiddleで書きました
    今度こそ確認していただけると思います
    http://jsfiddle.net/5MBRh/1/

    >>107
    その３問全て>>93を見て貰えればわかると思います
    >>96なんかの意見も出たので
    惑わせないように本当に最低限のコードに絞りました
    >>93を見ていただいた上でまだ何かありましたらお答えします
    今回はとにかく、JSON.stringifyで循環参照エラーが出る謎を究明したいです

    110 = 91 :

    >>108
    実際にはwindowを文字列化する予定はありませんが、
    それに近い巨大で複雑なものが対象になると思うので
    気持ち悪い現象を潰したいなあと思いまして
    循環参照チェックをしてるのにエラーが出るってことは
    ひょっとして文字列化する数が多いか、何かのパターンだと
    エラーが出るのかもしれないと思ってまして
    そうであっても何であっても、エラーが出ないように修正したいので
    まずなぜエラーが起きているのかを知りたいです

    111 = :

    >>109
    > その3問全て>>93を見て貰えればわかると思います
    >>93でも Object.isObject でObject型を判定できていないように読めます。
    横着せずに自分の言葉で説明してください。

    それからなぜ、>>104では>>93にあったコードが削られているのでしょう？
    たぶん、これでいいだろうと適当にコードを書いて再現性テストを省略してませんか？
    >>109のコードがあなたの期待する結果になっているのかすら怪しく思えてきます。

    > val.match(/^function [\s\S]+?}$/))
    typeof演算子で判定する方がよっぽどスマートだと思います。

    正直、後出し情報が多すぎて読む気が失せます。
    あまりに長引くようなら適当なところで降りさせて頂きます。

    113 = :

    >>109には>>93にあった function 判定がないですね。
    いずれにしても、
    Object.isObject = Object.isObject || function () {};
    こういう書き方をしている時点で isObject で判定しないといろいろとまずいと思いますが。

    ところで、Object.isObject は ES6 で入るとい噂がありましたが、
    http://people.mozilla.org/~jorendorff/es6-draft.html
    には掲載されてませんね。
    現在は仕様から抜けているのでしょうか。

    114 = :

    >>111
    横からだけど、

    > それからなぜ、>>104では>>93にあったコードが削られているのでしょう？
    > たぶん、これでいいだろうと適当にコードを書いて再現性テストを省略してませんか？
    > >>109のコードがあなたの期待する結果になっているのかすら怪しく思えてきます。
    原因は下記じゃない？

    > >>96なんかの意見も出たので
    > 惑わせないように本当に最低限のコードに絞りました

    必要なコード(functionの判定)まで削っちゃってる時点で本末転倒な気はするけど。

    というか、事情があってコードを削っているなら始めからそう書けばいいのに、何も書かずにやって後出しするから更に怒られるんだよな。
    無断で独断専行する人とコミュニケーションをとる場合は、逐一こちらがリードしてやらないといけないから大変だよ。

    115 = :

    空白文字で区切られた文字列を配列にしようと思います

    var s = "hoge moge　koge";
    var r = s.match(/([^\s]+)/g);
    console.dir(r);

    こうしたところ、\sに全角スペースもヒットしました
    望ましい動作ですが、これはJavaScriptの仕様でしょうか？

    116 :

    >>111
    ＞Object型を判定できていない
    それは関数の場合でしょうか？
    関数から伸びるメンバを追うとこのモデルでは根本的に破綻してしまうので
    関数は他の値と同等なただの値として文字列化しています
    このような慣用的なモデルでは関数から伸びるメンバが保有できなかったり
    配列がオブジェクトに化けたりする問題を抱えますが、一先ずこう、まとめたところで、
    関数をオブジェクトと見なしてないのは意図的なものです
    本気でやるのなら、ディスクリプタベースのモデル＋αにしないとはいけないと感じています
    とりあえずこれは意図的なものです

    ＞あなたの期待する結果
    最終的にはNodeとChromeAppで互いのAPIを叩き会える機構を作ろうと思ってまして、
    これはその計画の一部なので、どれも望んでいるものとは遠いとも言えますが、
    限定的な機能は有していますし、何よりもローカルで試していただけると、
    どれでもstringify問題が再現していただけると思います
    そこは適当ではなくちゃんと確認してあげています

    119 = :

    >>115
    > 望ましい動作ですが、これはJavaScriptの仕様でしょうか？
    "JavaScript" という仕様はありません。
    "ECMAScript" の仕様に準拠しています。
    ただし、古いIEは ECMAScript に完全準拠していないため、全角スペースを \s で認識しません。
    http://www.tagindex.com/kakolog/q4bbs/2301/2684.html

    120 = :

    >>119
    空白文字に全角空白も加えました
    ありがとうございました

    121 = :

    >>113
    > ところで、Object.isObject は ES6 で入るとい噂がありましたが、
    "May TC39 Review" で Object.isObject は ES.next 仕様から削除されているみたいだね。
    http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#current_working_draft

    124 = :

    まあいいってことよ。
    俺のアドバイスが役に立ったようだな。

    125 = :

    ここまで全部自演

    126 = :

    自演とジエンドって似てるよな。

    127 = :

    >>116
    > それは関数の場合でしょうか？
    function もありますが、"Implementation-defined." も考慮しています。(>>107でも書きました)
    http://people.mozilla.org/~jorendorff/es6-draft.html#sec-typeof-operator-runtime-semantics-evaluation

    Object.isObject が元々、存在するなら ES.next で入る予定だった Object 型判定を期待している可能性があります。
    その場合、元々の Object.isObject とあなたが定義した Object.isObject で実装に違いが出てきてしまいます。
    Object.isObject を拡張するなら厳密に Object 型を判定すべきだと思います。
    標準にこだわりがなく、手前実装したいなら関数スコープの中で function isObject でも定義すべきではないかと。

    128 = :

    >>127
    うん。俺もそう言おうと思っていた。

    129 :

    >>127,128
    それは思いまして
    >>118
    で遅れて謝りました

    130 = 129 :

    皆さんのアドバイスのおかけで５倍くらい早く解決出来ました
    本当にいろいろとどうもありがとうございました

    131 = :

    結局いつものパターンかよ

    132 = :

    ずっと俺のパターン

    133 = :

    >>127
    オブジェクトかどうかを確実に確認できる方法ってある？

    134 = :

    随分必死だな

    135 = :

    >>133
    function isObject(x){
    return ["undefined", "boolean", "number", "symbol", "string"].indexOf(typeof x) === -1 && x !== null
    }

    136 = :

    >>133
    対象が「Undefined型」「Null型」「Boolean型」「Number型」「String型」「Symbol型」のいずれでもない場合に「Object型」となります。
    泥臭いですが、現状ではこれしか思いつきません。
    もっとスマートな方法が ECMAScript 6 で用意されていればいいんですが、どなたかご存知ですか。

    137 = :

    >>136無い

    138 = :

    こういうのはlodashのコードを見ればいいよ。

    function isObject(value) {
    // check if the value is the ECMAScript language type of Object
    //http://es5.github.io/#x8
    // and avoid a V8 bug
    //http://code.google.com/p/v8/issues/detail?id=2291
    return !!(value && objectTypes[typeof value]);
    }

    var objectTypes = {
    'boolean': false,
    'function': true,
    'object': true,
    'number': false,
    'string': false,
    'undefined': false
    };

    139 = :

    document.allを忘れてた
    function isObject(x){
    return ["undefined", "boolean", "number", "symbol", "string"].indexOf(typeof x) === -1 && x !== null || x === document.all
    }

    140 = :

    >>139
    関数はtrue？

    141 = :

    >>137
    そうですか。残念です…。

    >>138
    "Implementation-defined" が考慮されてませんね。
    typeof value === 'foo' だったり、typeof value === 'length' だった場合に期待通りの結果を返さないバグが存在します。

    142 = :

    >>139
    document.all は undefined を返す仕様だから>>135でいいような。
    >>135を使用してミスするならその人の実装が悪いと思う。

    143 = :

    >>140
    YES

    144 = :

    >>142
    でもそれじゃ標準っぽくないよね
    標準のArray.isArrayの完璧さと比べたら残念

    145 = :

    >>139やっぱりこれダメだわ
    document.allがundefinedのケースを忘れてた

    146 = :

    >>141
    逆に"undefined"を返すオブジェクトだって現にあるわけだし……

    147 = :

    >>144
    「document.all は意図的に ECMAScript に違反している」と HTML 5 仕様にあるから、むしろ ECMAScript に違反する結果を返す実装が正しいと思う。
    ECMAScript に違反する実装が標準化されてしまっているんだから。
    まあ、二律違反だし、どちらが正しいとも言い切れないんだろうけどね。

    Firefox の RegExp (今は直ってるんだっけ？)でも意図的に仕様違反している実装があったと思うけど、そこまで対応して要ったらキリがない気がする。

    148 = :

    もっと短いの思いついた
    document.allはダメだけど

    function isObject(x){
    return x === Object(x)
    }

    149 = :

    >>146
    document.all は意図的名違反なので、"Implementation-defined" とは別問題ではないかと。
    "Implementation-defined" ははじめから決定されている仕様です。
    typeof 演算子が規定にない文字列を返す時にも、対象を「Object型」と判定しなければなりません。

    150 = :

    それは単なる拡張であってESには関係ないし
    付き合いきれませんねえ
    それを考えるんなら将来のtypeof評価なんかの
    オーバーロードを考えたほうがまだ価値がある


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

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

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