actionscript 3 - Why does delete( DictionaryInstance[ key ] ); fail? -
my app uses dictionary
protected _categorytovaluedict:dictionary = new dictionary();
to map something else.
now, @ point in application, need remove key dictionary
.
i implemented simple method:
public function setcategorynovalue( cat:tamodelcategory ):void { // delete( _categorytovaluedict[ cat ] ); var old:dictionary = _categorytovaluedict; _categorytovaluedict = new dictionary(); ( var key:* in old ) { if ( key != cat ) { _categorytovaluedict[ key ] = old[ key ]; } } }
if use [description of delete operator]
delete( _categorytovaluedict[ cat ] );
the app doesn't throw errors in normal mode. serialize external data structure external source [currently sharedobject], app isn't able de-serialize later on.
if use above coded manual iterative removal operation, de-serialize operation works expected , model appears in app.
the alternative should identical. shouldn't they?
thus, question: what's difference between 2 alternatives?
ps: question might related my previous one.
update-1
adobe explains on this page:
to make object referenced myobject eligible garbage collection, must remove references it. in case, must change value of myobject , delete myobject key mymap, shown in following code:
myobject = null; delete mymap[myobject];
is suppose typo. shouldn't read this:
delete mymap[myobject]; myobject = null;
why pass null-pointer mymap key?
okay, spent 2 hours or looking this, way more planning on spending looking @ this. intrigued.
i think may have uncovered legitimate bug in actionscript's amf encoding (or in how dictionary
class gets seralized via amf). bug effects uses amf, exact same bug reproduceable bytearray
, i'm going use demonstration purposes.
consider following code:
var d:dictionary = new dictionary(false); d["goodbye"] = "world"; d["hello"] = "world"; delete d["hello"] var ba:bytearray = new bytearray(); ba.writeobject(d); var len:uint = ba.position; ba.position = 0; for(var i:uint=0;i<len;i++) { trace(ba.readunsignedbyte().tostring(16)); }
the output be:
11 05 00 06 0f 67 6f 6f 64 62 79 65 06 0b 77 6f 72 6c 64
now if don't ever put "hello"
in key:
var d:dictionary = new dictionary(false); d["goodbye"] = "world"; var ba:bytearray = new bytearray(); ba.writeobject(d); var len:uint = ba.position; ba.position = 0; for(var i:uint=0;i<len;i++) { trace(ba.readunsignedbyte().tostring(16)); }
the output is:
11 03 00 06 0f 67 6f 6f 64 62 79 65 06 0b 77 6f 72 6c 64
notice length same, differ in second byte.
now lets @ serialization if don't delete "hello"
:
11 05 01 06 0b 68 65 6c 6c 6f 06 0b 77 6f 72 6c 64 06 0f 67 6f 6f 64 62 79 65 06 02
notice 05
in second byte same when deleted it. think specifying number of items in dictionary. "i think" because dug through documentation on amf0/3 quite while trying figure out whats going on here, because doesn't seem should serialization dictionary, consistent, don't it.
so think that's why hitting exception (specifically "end of file" error), because still thinks there should item in dictionary should de-serializing.
your alternate method works because constructing new dictionary , populating it... "internal counter" ever increasing, works charm.
another thing note, if set d["hello"] = undefined
, not throw exception, item not removed dictionary. key gets serialized value of undefined
in amf stream. resulting byte-stream longer if never there.
using object
doesn't seem exhibit same behavior. not doesn't not produce error, generated bytecode more in line amf0/3 documentation find adobe. , resulting "key" literally dropped serialization, in fact never there. i'm not sure special case using dictionary
(apparently undocumented amf3 datatype 0x11
), not play right deleting items out of it.
it seems legit bug me.
edit
so dug around bit more , found other people talking amf serilization of dictionary
.
0x11 : dictionary data type 0x05 : bit code: xxxx xxxy : if y == 0 x reference encoded object in stream : if y == 1 x number of key/val pairs in dictionary.
so if case 5&1 == 1
, 5>>1 == 2
, it's expecting 2 key/val pairs in "bad" serialized version.
Comments
Post a Comment