wonderflに昔、こんな感じでforkしてみたものがあったんですが、理由が分からなかった部分を調べたまとめ。
通常、for..inをした場合、Objectとして作成したものは出力できますが、カスタムクラスのプロパティだとそれができません。
//Objectだとできる
for(var i:uint = 0; i < LOOP; i++){
var id:String = 'id' + String(i+1);
var name:String = 'name' + String(i+1);
var obj:Object = new Object();
obj.id = id;
obj.name = name;
_listObject.push(obj);
}
for(i = 0; i < LOOP; i++){
var o:Object = _listObject[i];
for(var prop:String in o){
trace(o[prop]);//できる
}
}
//カスタムクラスのプロパティはでない
for(var j:uint = 0; j < LOOP; j++){
var id:String = 'id' + String(j+1);
var name:String = 'name' + String(j+1);
var obj:TestObject = new TestObject();
//TestObjectはidとnameをpublic変数に持つものとする
obj.id = id;
obj.name = name;
_listObject.push(obj);
}
for(j = 0; j < LOOP; j++){
var o:Object = _listObject[j];
for(var prop:String in o){
trace(o[prop]);//何も出力されない
}
}
何故できないのか、と考えてみたんですが、for..inする場合には、そのクラスでpropertyIsEnumerable(プロパティ名)というメソッドを使った時にtrueが帰ってくる必要がありそうです。
ただ、こちらのメソッド、Objectに定義されているものをoverrideすることはできないので、書く必要があるんですが、全てtrueが帰るようにしてもうまく動作しません。prototypeを拡張しても効果無しです。
しかし、たまたまいじっていたらpropertyIsEnumerableがtrueになった、というかfor..inで出力されるようになりました。そのクラスのprototypeにプロパティと同名の変数を定義した場合です。
Object型の場合は値を代入した瞬間に同様の処理をされているのか？とも思いますが、理由は良く分かりません。
どうせデバッグ用にしか使わないだろうので、処理速度がどう変わるのか、などは検証していません。これが自動化できれば凄く便利な気もします。ただそもそもプロパティの列挙をするためにプロパティを全て知らなければいけないという面倒さがありますし、整形して出力したければ、toStringを実装する時にそのように書いた方が楽な気がしますし。
というわけで、調べたことのメモでした。
