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 >
