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. > [[put]] Yes. > [[delete]] Yes. > [[deleteByIndex]] Probably. I think I’m using an alternate “remove by index” method internally, but I’ll probably name it something else to avoid issues. > [[defaultValue]] I’m not even sure what this means. I’ve implemented valueOf() and toString(). I’m not clear on when [[defaultValue]] is used. > [[hasProperty]] I implemented hasOwnProperty() I’m not sure we need to do anything else. > [[deepCopy]] Yes. AFAICT, copy() is the the same as [[deepCopy]] > [[descendants]] Yes. > [[equals]] Yes. > [[resolveValue]] Ditto. I implemented valueOf(). Not sure if it’s the same. > [[insert]] Yes. > [[replace]] Yes. > [[addInScopeNamespaces]] Yes. > [[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? On Feb 9, 2016, at 2:56 AM, Alex Harui <aha...@adobe.com> wrote: > 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 >> >
