Yes. The internal methods are definitely different than the public APIs. For example, there is both a [[Replace]] internal method as well as a replace() API. The two do very different things. I also just realized that there is both [[InScopeNamespaces]] and inScopeNamespaces().
You are right that I was confused by [[Length]] which does refer to the length of the internal list of properties and not the length(). However the spec does not specify bracket notation internally, so that’s not very clear. It could just be I’m not very experienced at reading specification documentation… ;-) I have implemented some of the internal methods/properties, but not all. I’m not sure it makes sense to implement them all. It could be it makes sense to modify things a bit, but right now my priority is to get all this working. Apparently, some feel that the ECMA spec has some problems with it which might have been patched[1], but I’m not sure exactly which. Right now, I’m pretty close to having all the methods in place (after quite a few rewrites). The only thing I have not even started on is filtering. I have no actually tried to compile any of this, so that will be a whole task in itself. (BTW, you can see what I currently have done in the e4x branch.) So here’s my current plan: 1. Finish up the methods (minus filtering) in the next day or two. 2. Sync up XML with the current FlexJS folder structure and get rid of some junk (like all the JXON classes). 3. Get this all to compile. 4. Figure out the whole filtering issue. 5. Create test cases. Once this is done (or mostly done), it probably makes sense to get a sanity check and decide whether to rewrite some of what I’ve done. Makes sense? [1]https://bugs.chromium.org/p/v8/issues/detail?id=235#c75 On Feb 8, 2016, at 7:09 AM, Alex Harui <aha...@adobe.com> wrote: > Harbs, > > Is it possible you are being tricked by the difference between the XML > length() method and the Object length property? The following outputs 1 > for me: > > var xml:XML = <node><child /></node>; > trace(xml.length()); > > > AFAICT, the spec is recommending an internal implementation that is not > quite a 1:1 mapping to the public API. It suggests keeping an ordered > list of child nodes based upon how the Insert function got called so that > if there is a "get" with a numeric property name, there is a specific > behavior (conversion to XMLList and subsequent access of the correct > child). It does not seem to specify that there are properties like [0], > [1], [2] on the XML object itself. Rather, the get function is called > with a numeric property name. > > I really hadn't looked at the spec in any great detail until tonight, but > it made me wonder if FalconJX should be outputting calls to insert, > replace, put, get, etc. We would add some sort of prefix and/or suffix to > the internal methods so they don't really appear in the public API. > > Thoughts? > -Alex > > On 2/7/16, 9:38 AM, "Harbs" <harbs.li...@gmail.com> wrote: > >> Yeah. Except an XML object always has a length of 0… AFAIK, xmlObj[1] >> always returns undefined. The only valid index on an XML object is 0 >> which returns the XML object (to blur the distinction between XMLList and >> XML). I think xmlList[0] is the same as xmlList[0][0][0][0]... >> >> I think I’m just going to ignore this part of the spec because I’m >> storing everything in a _children array and dealing with that. >> >> On Feb 7, 2016, at 6:59 PM, Andy Dufilie <andy.dufi...@gmail.com> wrote: >> >>> The insert code looks fine to me, assuming children of XML are stored as >>> properties "0", "1", "2", ... >>> It's shifting all children with index >= i and saving P starting at >>> child >>> index i. >>> >>> [[Put]] is overwriting a child at a given index, and >>> insertChildBefore/insertChildAfter/prependChild should be doing the same >>> type of operation as insert. >> >
