> 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.
I completely agree with these statements. Challenges are fun. ;-) Give me some time to put together my doc and let’s see where that goes. I think having a clear list of the issues should be helpful. Harbs > On Aug 2, 2017, at 11:52 AM, Greg Dove <greg.d...@gmail.com> wrote: > > 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. >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>> >> >>
