On 2/9/16, 12:55 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>> Are you >> implementing XMLList as an Array or dynamic class with numeric property >> names? > >I am using Object.defineProperty to assign the numeric property names. >There’s always length+1 numeric properties assigned. > >I was planning on adding a “0" property to XML as well. OK. If that becomes painful, we could try to call a get() method instead. > >> I don't think this is the same. The spec says resolveValue is added so >>it >> is functionality unique to XML and XMLList handling. valueOf is used by >> the runtime in other places. It looks like resolveValue is only used >>in a >> few specific cases. It might have to be completely handled in the AS >> implementation. I don't know if the compiler needs to do anything. It >> looks like if you have some XML like: >> >> var xml:XML = <node><child /></node> >> >> Then do: >> >> var myChild:XMLList = xml.myChild; >> >> then myChild will be assigned an empty XMLList since there is no myChild >> tag in xml. But amazingly, if you then do: >> >> myChild[0] = foo; >> >> The implementation is supposed to use resolveValue to add a myChild >> property to the xml so the net is: >> >> <node><child /><myChild>foo</myChild></node> > >Right. Every XMLList returned by public methods of XML has a targetObject >object which refers to “this” and when the XMLList is altered, that’s >supposed to be modified. (I have not done this bit yet.) I’m not sure why >I need resolveValue for this. Not sure either. I think it gives the XMLList a chance to create the property on the targetObject XML. -Alex
