This was marked as TODO, so it was “being tracked” on some level. There are currently 43 TODOs in codegen/js and 101 TODOs under compiler jx main total.
Those sound like a good place to start… ;-) On May 7, 2016, at 10:01 PM, Christofer Dutz <christofer.d...@c-ware.de> wrote: > > I agree that the initial version doesn't have to be perfect. But we have to > keep track of such places and make sure to clean them up as soon as we have > some time. Perhaps it would be a good idea if implementing something we know > is hacky, to create an Issue for cleaning up? > > It's just that tracking down stuff like this comes close to being impossible. > I was confused why the backend I put in when creating the COMPJSC instance > wasn't there when using it. I could only track that down by using an insanely > expensive property-access-breakpoint. > > Chris > ________________________________________ > Von: Josh Tynjala <joshtynj...@gmail.com> > Gesendet: Samstag, 7. Mai 2016 20:36:41 > An: dev@flex.apache.org > Betreff: Re: [FLEXJS] Probably found the reason for some of my problems ... > > Judging by the comments in the file, Mike meant to get rid of this class. > I'm guessing it was added as a temporary hack to get things up and running > as quickly as possible, which was a very important thing earlier in the > life of FalconJX. Sometimes, things that we know are > "super-duper-ultra-bad" are worth their cost in order to get momentum going. > > Indeed, though, now that the project is maturing, it may be a good time to > consider refactoring this part to clean things up a bit. > > - Josh > > On Sat, May 7, 2016 at 9:33 AM, Christofer Dutz <christofer.d...@c-ware.de> > wrote: > >> Ok ... in a final struggle to at least have something to show at my talk >> at ApacheCon I dug really deep into the compiler and noticed one thing: >> >> >> There's a class called: JSSharedData, which contains a set of public >> static variables for containing the state of a compilation (I guess). The >> problem is that the values inside are set by the constructors of the >> compilers ... well actually just MXMLJSC but as COMPJSC extends from that >> also from that. In the FlexJSToolGroup I create an instance of any tool the >> group has. First one of COMPJSC and then MXMLJSC. So when creating the >> MXMLJSC instance all the static global variables correctly initialized by >> COMPJSC are overwritten by those of MXMLJSC. The reason I didn't notice >> this, was that in my last attempt I only used MXMLJSC in my examples from >> Flexmojos. >> >> >> This "one state that's shared between compiler instances" is really bad as >> the VM isn't destroyed during the build, this means that eventually >> settings from one module could leak to another module. I guess it would be >> absolutely impossible to track down problems like this. "public >> static"-Variables for maintaining the State of an instance of anything is >> super-duper-ultra-bad ... we have to change this. >> >> >> Chris >>
