That sounds great Harbs. It will be interesting to see the gzip comparisons.
I suspect that there would have to be massive quantities of redundant initializations to cause a meaningful performance impact, but keen to see the data. >From my perspective I think the baseline should be as3 compatibility, which I believe is what any new user to FlexJS will be hoping for (expecting?). In much the same way Josh described the feathers codebase, I can't imagine an enterprise flex user aiming to port a large flex codebase not wanting flexjs to be more reliable out-of-the-box, with the subsequent possibility to tune things based on granular settings and a specific 'coding style'. My guess is that they would prefer to avoid 'Pain as you go' from incompatible as3 justified by pay as you go. The challenge for us then is to come up with the optimizations that both you and Alex have mentioned, so that wherever possible the unneccessary initializations are not expressed in the js output while still maintaining as3 compatibility. Meanwhile the (possibly granular) options to globally omit initializations could be opt-in. I'm calling tron on this. But it's just my opinion of what users want. We should canvas the users group or run a survey to see what prospective flexjs users prefer/expect. I don't really care about this for my own use (so long as the option to switch initializations on is available). I care about it in terms of what impact it could have on first experiences that many users will have, and how much that will affect the popularity of FlexJS. I've said my piece. I will leave it at that. On Wed, Aug 2, 2017 at 8:25 PM, Harbs <harbs.li...@gmail.com> wrote: > I’m planning on using the new compiler options to compile my app with and > without initialization. I want to compare the app size of those two options > after gzipping to see if there’s an impact on code size. > > I’d also like to write up a doc with the pros and cons of both approaches > and see if I can come up with a list of use cases where initialized vs > uninitialized values behave differently. It might be interesting to see how > many can be resolved without initialization. > > If nothing else, it can serve as a guide for developers deciding which > compiler option to use. > > Thanks, > Harbs > > > On Aug 2, 2017, at 7:34 AM, 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. > >>>>>> > >>>>>> > >>>> > >>>> > >> > > > >
