I like the idea of having the FlexJS framework specify non-initialization with its config files, and then most users will get initialization by default (obviously, with the option to have non-initialization too, if desired).
- Josh On Wed, Aug 2, 2017 at 2:16 PM, Alex Harui <aha...@adobe.com.invalid> wrote: > We have flex-config.xml, air-config.xml, js-config.xml, etc. These config > files are (or can be) different sets of defaults. > > Meanwhile, we currently build the FlexJS framework via > compile-swf-config.xml and compile-js-config.xml and its equivalent in > pom.xml. I have no problem using different defaults for the FlexJS > framework and different defaults for compiling apps. We already supply > certain kinds of optimizations via @flexjsignorcoercion. IOW, there is > precedence for controlling the kinds of JS output we generate. > > We provide an Express component set with different defaults than Basic and > produces fatter slower apps but should make it easier to get your app up > and running. We can certainly have the compiler start out by producing > fatter slower code as well as long as it doesn't give a negative first > impression of app size. We just have to make it possible to shave off > code to improve download size and performance if/when someone needs it. > > Regarding the list of nullable types, I agree there should be some > wildcard for all instances. > > My 2 cents, > -Alex > > On 8/2/17, 7:06 AM, "Josh Tynjala" <joshtynj...@gmail.com> wrote: > > >> 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. > >> >>>>> > >> >>>>> > >> >>> > >> >>> > >> > > >> > >> > >
