OK, I looked at what is coded up so far on the compiler side and looked at the spec some more. We've taken the approach so far of making up public method names that have a pretty close mapping to the internal methods. It seems to me that we should not try to obfuscate the method names. So what if there is a setChild() or filter() method on our JS version of XML.
One notable difference in the mapping is that the compiler has already parsed the @ prefix for attributes into its own token, so it makes it easier to call setAttribute() vs setChild() so the internal implementation doesn't have to bother to determine what is being "put". Here's what I came up with: [[get]] maps to attribute() and child() methods. I think we need to handle someXML[x] where x is a numeric property name (0, 1, 2, 3, etc). We could see if we know the key is an integer and output elements()[x]. [[put]] maps to setAttribute() and setChild() methods. The setAttribute() and setChild() implementations should call [[deepCopy]] on the value. I don't think the compiler should call [[deepCopy]]. [[delete]] maps to removeChild(). [[deleteByIndex]] maps to removeChildAt() methods. The implementation probably needs to throw the TypeError if removeChildAt() is called on an XML object. For now, I think you'll get an NPE if there isn't a removeChildAt() on XML. [[defaultValue]] This is not currently implemented in the compiler. We should probably take this on when we get around to handling other ActionScript automatic type conversions. [[hasProperty]] This is not currently implemented in the compiler. [[deepCopy]] I think the compiler doesn't need to do anything here and the implementation will handle it. [[descendants]] The compiler is mapping ".." to descendants() calls. [[equals]] The compiler will have to look for "==" and call and equals() method. [[resolveValue]] I'm not quite sure what to do here. [[insert]] I think the compiler doesn't need to do anything here and the implementation will handle it. [[replace]] I think the compiler doesn't need to do anything here and the implementation will handle it. [[addInScopeNamespaces]] I think the compiler doesn't need to do anything here and the implementation will handle it. [[append]] maps to concat() Another area of work is handling things like: -typeof -instanceof These are already caught and converted to calls to org.apache.flex.utils.Language. I think the Language implementation will have to become smart about XML. Thoughts? -Alex On 2/8/16, 8:30 AM, "Alex Harui" <aha...@adobe.com> wrote: > > >On 2/8/16, 1:00 AM, "Harbs" <harbs.li...@gmail.com> wrote: >>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'm not good at reading specs, probably because I find it boring. This >spec [1] seems to describe some not-so-common notation like the double >brackets in section 9.1.1. > >[1] >http://www.ecma-international.org/publications/files/ECMA-ST-WITHDRAWN/Ecm >a >-357.pdf > > >> >>I have implemented some of the internal methods/properties, but not all. >>I’m not sure it makes sense to implement them all. > >Implementing the internal methods/properties does not seem to be required >by the spec. But which ones are you thinking of skipping? > >> >>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. > >There could certainly be bugs everywhere: in the spec, in the Flash >implementation, in the Mozilla implementation which apparently isn't >available anymore. > >> >>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.) > >I have not looked closely at what you committed, but I'm quite excited >that you are making any sort of progress on this. > >> >>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? > >Sounds reasonable. I spent more time skimming the spec this morning. I >think there are a lot more cases that the compiler doesn't handle. You >and I may need to coordinate on when to work on those things, not that I'm >looking forward to having to do all that work. The key to success looks >like it will be how the compiler can or can't know the resolved type of >something. The spec is about how to change the runtime, but we can't >change the runtime and need to detect when an object is XML and generate >different code. I have some concerns about whether that will start to >affect compiler performance, but I guess we'll just have to see, or maybe >I'll put XML checking in some conditional so you can opt in. > >The link you posted didn't seem to point to any particular bug in E4X, but >it was an interesting discussion in how the JS runtimes don't want to take >on the complexity of E4X. It would be interesting if there is a >functional subset of E4X that we could implement that would draw in the >E4X folks, especially the Node folks that appear to be stuck with handling >XML documents for legacy support reasons. > >> >>[1]https://bugs.chromium.org/p/v8/issues/detail?id=235#c75 > >-Alex >
