> To me, this is all related to PAYG. To me, making the compiler generate PAYG code by default sounds like the FlexJS framework leaking into the rest of the ecosystem. Maybe this is a place where mxmlc and asjsc should go in different directions. It makes perfect sense to me for the compiler to do PAYG by default for the FlexJS framework, but the rest of the world should get the a better user experience with more compatibility by default (with the option to opt into non-initialized PAYG mode). Thoughts?
> 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. It's an interesting idea. For nullable types, that list could get huge, though. Boolean, int, uint, and Number are all special, but basically everything else is nullable. I think there should still be a way to say "I want everything initialized". > BTW, IIRC, VarDeclarationEmitter only handles local variables and not instance variables. For some reason, I thought I remembered locals and members using the same emitter. I'll update it elsewhere for members too. - Josh On Tue, Aug 1, 2017 at 9:34 PM, Alex Harui <aha...@adobe.com.invalid> wrote: > 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. > >>>>> > >>>>> > >>> > >>> > > > >
