flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: [FLEXJS] Probably found the reason for some of my problems ...
Date Sat, 07 May 2016 19:06:49 GMT
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.dutz@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
> 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 <joshtynjala@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.dutz@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

View raw message