私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.111 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
確かにグローバルオブジェクトを渡すのだから、グローバルオブジェクトが特定できる形にしないと意味がないな。
HTMLがない条件ではグローバルオブジェクトは如何様にも変化する。
HTMLがない条件ではグローバルオブジェクトは如何様にも変化する。
再現してもらいやすいようにHTMLファイルにして書き直しました
http://ideone.com/CQA3e3
http://ideone.com/CQA3e3
>>103
なるほど
多分グローバルオブジェクトとフレームが繋がっていて
走査中に跨ごうとしてしまったんだと思います
ローカルの何もないHTML上で確認していたので気づきませんでした
ご指摘ありがとうございます
なるほど
多分グローバルオブジェクトとフレームが繋がっていて
走査中に跨ごうとしてしまったんだと思います
ローカルの何もないHTML上で確認していたので気づきませんでした
ご指摘ありがとうございます
>>105
なるほどじゃねえよ糞野郎
なるほどじゃねえよ糞野郎
>>104
ざっとしか読んでませんが、気がついた点がいくつか。
・isObject でObject型を完全に判定できていません。typeof obj === 'hoge' や typeof obj === 'function' もObject型です。
・JSONは function を許容しませんので function だった場合に文字列化する処理が必要です。
・byXJSON(xjson, nativeFunc) の nativeFuncの処理がありません。そもそも、"netive code" なfunctionに限定する意味は何でしょう？
ざっとしか読んでませんが、気がついた点がいくつか。
・isObject でObject型を完全に判定できていません。typeof obj === 'hoge' や typeof obj === 'function' もObject型です。
・JSONは function を許容しませんので function だった場合に文字列化する処理が必要です。
・byXJSON(xjson, nativeFunc) の nativeFuncの処理がありません。そもそも、"netive code" なfunctionに限定する意味は何でしょう？
>>105
window にパスするように作るなら当然、frameも考慮する必要がありますが、そこは考慮しなくて良いのでしょうか。
そもそも、どこまで機能するものを求めているのか、要求仕様が見えてきません。
frameを考慮しなくて良いなら、window 以外の引数をサンプルにすべきだと思いますが。
window にパスするように作るなら当然、frameも考慮する必要がありますが、そこは考慮しなくて良いのでしょうか。
そもそも、どこまで機能するものを求めているのか、要求仕様が見えてきません。
frameを考慮しなくて良いなら、window 以外の引数をサンプルにすべきだと思いますが。
jsfiddleで書きました
今度こそ確認していただけると思います
http://jsfiddle.net/5MBRh/1/
>>107
その３問全て>>93を見て貰えればわかると思います
>>96なんかの意見も出たので
惑わせないように本当に最低限のコードに絞りました
>>93を見ていただいた上でまだ何かありましたらお答えします
今回はとにかく、JSON.stringifyで循環参照エラーが出る謎を究明したいです
今度こそ確認していただけると思います
http://jsfiddle.net/5MBRh/1/
>>107
その３問全て>>93を見て貰えればわかると思います
>>96なんかの意見も出たので
惑わせないように本当に最低限のコードに絞りました
>>93を見ていただいた上でまだ何かありましたらお答えします
今回はとにかく、JSON.stringifyで循環参照エラーが出る謎を究明したいです
>>108
実際にはwindowを文字列化する予定はありませんが、
それに近い巨大で複雑なものが対象になると思うので
気持ち悪い現象を潰したいなあと思いまして
循環参照チェックをしてるのにエラーが出るってことは
ひょっとして文字列化する数が多いか、何かのパターンだと
エラーが出るのかもしれないと思ってまして
そうであっても何であっても、エラーが出ないように修正したいので
まずなぜエラーが起きているのかを知りたいです
実際にはwindowを文字列化する予定はありませんが、
それに近い巨大で複雑なものが対象になると思うので
気持ち悪い現象を潰したいなあと思いまして
循環参照チェックをしてるのにエラーが出るってことは
ひょっとして文字列化する数が多いか、何かのパターンだと
エラーが出るのかもしれないと思ってまして
そうであっても何であっても、エラーが出ないように修正したいので
まずなぜエラーが起きているのかを知りたいです
>>109
> その3問全て>>93を見て貰えればわかると思います
>>93でも Object.isObject でObject型を判定できていないように読めます。
横着せずに自分の言葉で説明してください。
それからなぜ、>>104では>>93にあったコードが削られているのでしょう？
たぶん、これでいいだろうと適当にコードを書いて再現性テストを省略してませんか？
>>109のコードがあなたの期待する結果になっているのかすら怪しく思えてきます。
> val.match(/^function [\s\S]+?}$/))
typeof演算子で判定する方がよっぽどスマートだと思います。
正直、後出し情報が多すぎて読む気が失せます。
あまりに長引くようなら適当なところで降りさせて頂きます。
> その3問全て>>93を見て貰えればわかると思います
>>93でも Object.isObject でObject型を判定できていないように読めます。
横着せずに自分の言葉で説明してください。
それからなぜ、>>104では>>93にあったコードが削られているのでしょう？
たぶん、これでいいだろうと適当にコードを書いて再現性テストを省略してませんか？
>>109のコードがあなたの期待する結果になっているのかすら怪しく思えてきます。
> val.match(/^function [\s\S]+?}$/))
typeof演算子で判定する方がよっぽどスマートだと思います。
正直、後出し情報が多すぎて読む気が失せます。
あまりに長引くようなら適当なところで降りさせて頂きます。
>>109には>>93にあった function 判定がないですね。
いずれにしても、
Object.isObject = Object.isObject || function () {};
こういう書き方をしている時点で isObject で判定しないといろいろとまずいと思いますが。
ところで、Object.isObject は ES6 で入るとい噂がありましたが、
http://people.mozilla.org/~jorendorff/es6-draft.html
には掲載されてませんね。
現在は仕様から抜けているのでしょうか。
いずれにしても、
Object.isObject = Object.isObject || function () {};
こういう書き方をしている時点で isObject で判定しないといろいろとまずいと思いますが。
ところで、Object.isObject は ES6 で入るとい噂がありましたが、
http://people.mozilla.org/~jorendorff/es6-draft.html
には掲載されてませんね。
現在は仕様から抜けているのでしょうか。
>>111
横からだけど、
> それからなぜ、>>104では>>93にあったコードが削られているのでしょう？
> たぶん、これでいいだろうと適当にコードを書いて再現性テストを省略してませんか？
> >>109のコードがあなたの期待する結果になっているのかすら怪しく思えてきます。
原因は下記じゃない？
> >>96なんかの意見も出たので
> 惑わせないように本当に最低限のコードに絞りました
必要なコード(functionの判定)まで削っちゃってる時点で本末転倒な気はするけど。
というか、事情があってコードを削っているなら始めからそう書けばいいのに、何も書かずにやって後出しするから更に怒られるんだよな。
無断で独断専行する人とコミュニケーションをとる場合は、逐一こちらがリードしてやらないといけないから大変だよ。
横からだけど、
> それからなぜ、>>104では>>93にあったコードが削られているのでしょう？
> たぶん、これでいいだろうと適当にコードを書いて再現性テストを省略してませんか？
> >>109のコードがあなたの期待する結果になっているのかすら怪しく思えてきます。
原因は下記じゃない？
> >>96なんかの意見も出たので
> 惑わせないように本当に最低限のコードに絞りました
必要なコード(functionの判定)まで削っちゃってる時点で本末転倒な気はするけど。
というか、事情があってコードを削っているなら始めからそう書けばいいのに、何も書かずにやって後出しするから更に怒られるんだよな。
無断で独断専行する人とコミュニケーションをとる場合は、逐一こちらがリードしてやらないといけないから大変だよ。
空白文字で区切られた文字列を配列にしようと思います
var s = "hoge moge koge";
var r = s.match(/([^\s]+)/g);
console.dir(r);
こうしたところ、\sに全角スペースもヒットしました
望ましい動作ですが、これはJavaScriptの仕様でしょうか？
var s = "hoge moge koge";
var r = s.match(/([^\s]+)/g);
console.dir(r);
こうしたところ、\sに全角スペースもヒットしました
望ましい動作ですが、これはJavaScriptの仕様でしょうか？
>>111
＞Object型を判定できていない
それは関数の場合でしょうか？
関数から伸びるメンバを追うとこのモデルでは根本的に破綻してしまうので
関数は他の値と同等なただの値として文字列化しています
このような慣用的なモデルでは関数から伸びるメンバが保有できなかったり
配列がオブジェクトに化けたりする問題を抱えますが、一先ずこう、まとめたところで、
関数をオブジェクトと見なしてないのは意図的なものです
本気でやるのなら、ディスクリプタベースのモデル＋αにしないとはいけないと感じています
とりあえずこれは意図的なものです
＞あなたの期待する結果
最終的にはNodeとChromeAppで互いのAPIを叩き会える機構を作ろうと思ってまして、
これはその計画の一部なので、どれも望んでいるものとは遠いとも言えますが、
限定的な機能は有していますし、何よりもローカルで試していただけると、
どれでもstringify問題が再現していただけると思います
そこは適当ではなくちゃんと確認してあげています
＞Object型を判定できていない
それは関数の場合でしょうか？
関数から伸びるメンバを追うとこのモデルでは根本的に破綻してしまうので
関数は他の値と同等なただの値として文字列化しています
このような慣用的なモデルでは関数から伸びるメンバが保有できなかったり
配列がオブジェクトに化けたりする問題を抱えますが、一先ずこう、まとめたところで、
関数をオブジェクトと見なしてないのは意図的なものです
本気でやるのなら、ディスクリプタベースのモデル＋αにしないとはいけないと感じています
とりあえずこれは意図的なものです
＞あなたの期待する結果
最終的にはNodeとChromeAppで互いのAPIを叩き会える機構を作ろうと思ってまして、
これはその計画の一部なので、どれも望んでいるものとは遠いとも言えますが、
限定的な機能は有していますし、何よりもローカルで試していただけると、
どれでもstringify問題が再現していただけると思います
そこは適当ではなくちゃんと確認してあげています
>>115
> 望ましい動作ですが、これはJavaScriptの仕様でしょうか？
"JavaScript" という仕様はありません。
"ECMAScript" の仕様に準拠しています。
ただし、古いIEは ECMAScript に完全準拠していないため、全角スペースを \s で認識しません。
http://www.tagindex.com/kakolog/q4bbs/2301/2684.html
> 望ましい動作ですが、これはJavaScriptの仕様でしょうか？
"JavaScript" という仕様はありません。
"ECMAScript" の仕様に準拠しています。
ただし、古いIEは ECMAScript に完全準拠していないため、全角スペースを \s で認識しません。
http://www.tagindex.com/kakolog/q4bbs/2301/2684.html
>>113
> ところで、Object.isObject は ES6 で入るとい噂がありましたが、
"May TC39 Review" で Object.isObject は ES.next 仕様から削除されているみたいだね。
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#current_working_draft
> ところで、Object.isObject は ES6 で入るとい噂がありましたが、
"May TC39 Review" で Object.isObject は ES.next 仕様から削除されているみたいだね。
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#current_working_draft
>>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 でも定義すべきではないかと。
> それは関数の場合でしょうか？
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 でも定義すべきではないかと。
>>127
うん。俺もそう言おうと思っていた。
うん。俺もそう言おうと思っていた。
皆さんのアドバイスのおかけで５倍くらい早く解決出来ました
本当にいろいろとどうもありがとうございました
本当にいろいろとどうもありがとうございました
>>127
オブジェクトかどうかを確実に確認できる方法ってある？
オブジェクトかどうかを確実に確認できる方法ってある？
>>133
function isObject(x){
return ["undefined", "boolean", "number", "symbol", "string"].indexOf(typeof x) === -1 && x !== null
}
function isObject(x){
return ["undefined", "boolean", "number", "symbol", "string"].indexOf(typeof x) === -1 && x !== null
}
>>133
対象が「Undefined型」「Null型」「Boolean型」「Number型」「String型」「Symbol型」のいずれでもない場合に「Object型」となります。
泥臭いですが、現状ではこれしか思いつきません。
もっとスマートな方法が ECMAScript 6 で用意されていればいいんですが、どなたかご存知ですか。
対象が「Undefined型」「Null型」「Boolean型」「Number型」「String型」「Symbol型」のいずれでもない場合に「Object型」となります。
泥臭いですが、現状ではこれしか思いつきません。
もっとスマートな方法が ECMAScript 6 で用意されていればいいんですが、どなたかご存知ですか。
>>136無い
こういうのは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
};
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
};
document.allを忘れてた
function isObject(x){
return ["undefined", "boolean", "number", "symbol", "string"].indexOf(typeof x) === -1 && x !== null || x === document.all
}
function isObject(x){
return ["undefined", "boolean", "number", "symbol", "string"].indexOf(typeof x) === -1 && x !== null || x === document.all
}
>>139
関数はtrue？
関数はtrue？
>>140
YES
YES
>>139やっぱりこれダメだわ
document.allがundefinedのケースを忘れてた
document.allがundefinedのケースを忘れてた
>>141
逆に"undefined"を返すオブジェクトだって現にあるわけだし……
逆に"undefined"を返すオブジェクトだって現にあるわけだし……
>>144
「document.all は意図的に ECMAScript に違反している」と HTML 5 仕様にあるから、むしろ ECMAScript に違反する結果を返す実装が正しいと思う。
ECMAScript に違反する実装が標準化されてしまっているんだから。
まあ、二律違反だし、どちらが正しいとも言い切れないんだろうけどね。
Firefox の RegExp (今は直ってるんだっけ？)でも意図的に仕様違反している実装があったと思うけど、そこまで対応して要ったらキリがない気がする。
「document.all は意図的に ECMAScript に違反している」と HTML 5 仕様にあるから、むしろ ECMAScript に違反する結果を返す実装が正しいと思う。
ECMAScript に違反する実装が標準化されてしまっているんだから。
まあ、二律違反だし、どちらが正しいとも言い切れないんだろうけどね。
Firefox の RegExp (今は直ってるんだっけ？)でも意図的に仕様違反している実装があったと思うけど、そこまで対応して要ったらキリがない気がする。
もっと短いの思いついた
document.allはダメだけど
function isObject(x){
return x === Object(x)
}
document.allはダメだけど
function isObject(x){
return x === Object(x)
}
>>146
document.all は意図的名違反なので、"Implementation-defined" とは別問題ではないかと。
"Implementation-defined" ははじめから決定されている仕様です。
typeof 演算子が規定にない文字列を返す時にも、対象を「Object型」と判定しなければなりません。
document.all は意図的名違反なので、"Implementation-defined" とは別問題ではないかと。
"Implementation-defined" ははじめから決定されている仕様です。
typeof 演算子が規定にない文字列を返す時にも、対象を「Object型」と判定しなければなりません。
それは単なる拡張であってESには関係ないし
付き合いきれませんねえ
それを考えるんなら将来のtypeof評価なんかの
オーバーロードを考えたほうがまだ価値がある
付き合いきれませんねえ
それを考えるんなら将来のtypeof評価なんかの
オーバーロードを考えたほうがまだ価値がある
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
JavaScript スレッド一覧へ類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.141 + (881) - [97%] - 2021/4/19 9:00
- + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
- + JavaScript の質問用スレッド vol.101 + (1001) - [97%] - 2012/7/16 14:15
- + JavaScript の質問用スレッド vol.110 + (1001) - [97%] - 2013/10/13 14:01
- + JavaScript の質問用スレッド vol.112 + (1001) - [97%] - 2013/11/27 16:46
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/1/25 12:46
- + JavaScript の質問用スレッド vol.114 + (1001) - [97%] - 2014/5/3 10:45
- + JavaScript の質問用スレッド vol.115 + (1001) - [97%] - 2014/5/29 16:16
- + JavaScript の質問用スレッド vol.116 + (1002) - [97%] - 2014/7/1 0:45
- + JavaScript の質問用スレッド vol.117 + (1009) - [97%] - 2014/8/5 3:30
- + JavaScript の質問用スレッド vol.118 + (1002) - [97%] - 2014/8/29 22:30
- + JavaScript の質問用スレッド vol.119 + (1002) - [97%] - 2014/10/3 15:30
- + JavaScript の質問用スレッド vol.121 + (1001) - [97%] - 2022/11/29 16:30
- + JavaScript の質問用スレッド vol.121 + (1001) - [97%] - 2015/1/1 18:30
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/3/15 21:30
- + JavaScript の質問用スレッド vol.141 + (1001) - [97%] - 2019/9/22 23:15
トップメニューへ / →のくす牧場書庫について