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/Ecma -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
