> 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. > 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. On Feb 9, 2016, at 8:04 PM, Alex Harui <aha...@adobe.com> wrote: > > > On 2/9/16, 1:39 AM, "Harbs" <harbs.li...@gmail.com> wrote: > >> Thanks for this. It’s really good to have someone else go through this >> and give me a sanity check. Most of this is very much in line with what >> I’ve already done. >> >> Some comments: >> >>> [[get]] >> someXML[x] is only valid when x is 0 and that returns someXML and not a >> child of someXML. > > OK, I hadn't realized that. That makes me wonder if we need to intercept > all bracket calls on XML and XMLList and call child(int). Are you > implementing XMLList as an Array or dynamic class with numeric property > names? It might be better to implement a get() method and have the > compiler call that with ints or property names. Apparently we are > supposed to blur the distinction between XML and XMLList. I suppose > another trick would be to create a "0" property on XML. > >> >>> [[defaultValue]] >> I’m not even sure what this means. I’ve implemented valueOf() and >> toString(). I’m not clear on when [[defaultValue]] is used. > > I think it is used in automatic type conversion. See [1]. Maybe you can > just implement valueOf() to call toString(). > >> >>> [[hasProperty]] >> I implemented hasOwnProperty() I’m not sure we need to do anything else. > > OK. Makes sense. > >> >>> [[deepCopy]] >> Yes. AFAICT, copy() is the the same as [[deepCopy]] > > Agreed. > >> >>> [[resolveValue]] >> Ditto. I implemented valueOf(). Not sure if it’s the same. > > 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> > >> >>> [[append]] maps to concat() >> That’s for XMLList. (which I’ve already done) What do we do for XML? Not >> implement it? throw an error? > > If I understand the spec, it never gets called on XML. When the compiler > sees the "+" operator, the generated code is supposed to generate a new > XMLList. > > Thanks for working on the E4X. It will be pretty cool when it starts > working. > > -Alex > > [1] > http://www.i-programmer.info/programming/javascript/2951-objects-with-value > s.html >
