To me, this is all related to PAYG. And also, coding "style" matters. If we want to allow every possible existing AS statement work as-is, then we must initialize every variable that has a different default in JS.
I thought the results of the set of tests I ran was that some of those patterns that expose the differences between JS and AS default values are less efficient and/or less common that other patterns. IOW, as mentioned up thread "if (someBoolean === false)" is less code and just as fast if you rewrite it as "if (!someBoolean)". And so, my recommendation for the framework code is that we take the time to try to use these more common patterns and thus not need to initialize every variable. Another outcome of the tests was the question as to whether our compiler ought to some day learn to rewrite these inefficient patterns to further reduce cases where initialization is required. And to also ponder whether Google Closure Compiler may some day get around to rewriting these patterns. Either way, if we know the framework works just fine with uninitialized variables and may even be smaller and faster than if we used other patterns that care about initialization values, we can allow all kinds of output options for user code. I just looked at the commit a few minutes ago. It is ok for now, but I'd suggest making the option not tri-state, but rather, list the Classes that should be initialized. Maybe your code doesn't care if Numbers are initialized but does care that Booleans are. Then you can opt in on Boolean initialization and not pay the price for Number initialization. So the option might look like: -initialize-types=Boolean,Number,* Or something like that. Essentially, let folks control how verbose the output is so they can decide whether to change their code or change the output as needed instead of just-in-case. In this same area of code, we should probably add a warning about variables being uninitialized and having different default values. BTW, IIRC, VarDeclarationEmitter only handles local variables and not instance variables. My 2 cents, -Alex On 8/1/17, 8:48 PM, "Harbs" <harbs.li...@gmail.com> wrote: >What I mean is that if we can somehow have the values uninitialized in >JS, but in all cases where uninitialized values somehow diverge with >ActionScript behavior be solved (so the use cases would behave >correctly), then we’d have the advantages of undefined together with >expected AS behavior. > >I don’t know that this is possible, but that would be ideal in my book. > >If that’s not possible, then yes, I agree that two compiler options is >the best we can do. > >Hope that’s clearer, >Harbs > >> On Aug 2, 2017, at 1:49 AM, Greg Dove <greg.d...@gmail.com> wrote: >> >> I’d prefer if we could somehow get the best of both worlds. >> >> Sorry Harbs, but I don't get it. I think the agreement is already to >>'have >> the best of both worlds'. >> The issue is what the default should be. I know that you don't think you >> could have both behaviours as the default :). >> >> If we take away personal preferences, and think in terms of where >> developers will be coming from for FlexJS, and if we assume that this >> includes a large proportion of people who are already familiar with >> actionscript and therefore have expectations based on that familiarity, >> then I don't see how having default behaviour that is different to those >> expectations will be helpful to the uptake in use of flexjs. >> >> If it is not the case then we need to have documentation that supports >>the >> divergence from official actionscript language documentation elsewhere, >>and >> the hope that new users will read it as the authoritative source. >> >> >> On Wed, Aug 2, 2017 at 10:31 AM, Harbs <harbs.li...@gmail.com> wrote: >> >>> I’d prefer if we could somehow get the best of both worlds. >>> >>> I don’t see a solution to that dilemma at the moment, but maybe we’ll >>>come >>> up with something... >>> >>> Harbs >>> >>>> On Aug 2, 2017, at 1:24 AM, Josh Tynjala <joshtynj...@gmail.com> >>>>wrote: >>>> >>>> Don't get me wrong. If you see value in it, then we definitely >>>>shouldn't >>>> remove it as an option. However, for compatibility with the existing >>>> language, I'd prefer to see initialization be the default instead. >>>> >>>> - Josh >>>> >>>> On Tue, Aug 1, 2017 at 3:14 PM, Harbs <harbs.li...@gmail.com> wrote: >>>> >>>>> Any maybe vice versa... ;-p >>>>> >>>>> Alex was planning on looking into whether he can solve the boolean >>>>> problem, so let’s hold off until he does that. >>>>> >>>>> I think comparing two booleans is pretty rare although I have already >>> run >>>>> into if(myBool == false) not working. Changing it to if(!myBool) was >>> simple >>>>> enough, but I do agree with you that it’s currently broken. >>>>> >>>>> For now, we’re going to have to agree to disagree on initializing >>> values. >>>>> I’ve seen a lot of value in leaving them undefined. It makes it >>>>>really >>>>> clear while debugging whether the value has been set or not. >>>>> >>>>> Harbs >>>>> >>>>>> On Aug 2, 2017, at 12:54 AM, Josh Tynjala <joshtynj...@gmail.com> >>> wrote: >>>>>> >>>>>> Maybe I'll convince others eventually. >>>>> >>>>> >>> >>> >
