Reflection support was opt-in. Hopefully it still is. As in, if your app doesn't call any code that uses the reflection data structures they are not in the minified output.
I had not realised that (nor had I checked), that sounds great. On Wed, Jul 12, 2017 at 5:20 PM, Alex Harui <aha...@adobe.com.invalid> wrote: > Reflection support was opt-in. Hopefully it still is. As in, if your app > doesn't call any code that uses the reflection data structures they are > not in the minified output. > > DataBinding in general requires exports. Any use of bracket access does > as well. But yes, I believe a smarter compiler can reduce the number of > exports. > > I'm pretty sure --generate_exports is required to turn our @export > notation into symbols in the minified output. But the main app has a > generated exportSymbol call so --generate_exports will not always be > required for FlexJS. > > Again, though, I think this optimization isn't urgent. > > goog.DEBUG is already being used in Language.as. > > -Alex > > On 7/11/17, 4:01 PM, "Greg Dove" <greg.d...@gmail.com> wrote: > > >I'll try those things, I have not tried any of those options so far. > > > >Future need to support modules has been mentioned as a reason for keeping > >@export before. > > > >Another is to support reflection (in its current form). Reflection support > >probably needs to be opt-in, I think this has been discussed before also. > > > >Perhaps another in this case might be to support constant bindings. > >This is one area that could probably benefit from jx-compiler optimisation > >for primitive constant lookups - iirc I *think* that constant bindings are > >still happening via bracket access, and probably could simply be replaced > >by the literal values for string, number etc. > > > > > > > > > >On Wed, Jul 12, 2017 at 9:57 AM, Harbs <harbs.li...@gmail.com> wrote: > > > >> Hi Greg, > >> > >> There probably is too much use of @export. @const is probably more > >>correct > >> than @export — as long as we are sure that there’s no use of bracket > >> notation anywhere. I’d be interested in hearing your findings. > >> > >> Personally, I’m not sure there’s a lot of value to be using @export at > >>all > >> unless an app is using modules of some sort (which I’m not even sure > >>how to > >> do with FlexJS). (but I might be missing something with the @export tag) > >> > >> What happens if the compiler is run without --generate_exports? Do the > >> @exports get stripped out? If yes, is there some kind of “super export”? > >> There needs to be some way to invoke the app… > >> > >> Harbs > >> > >> > On Jul 11, 2017, at 11:40 PM, Greg Dove <greg.d...@gmail.com> wrote: > >> > > >> > Guys, we certainly have been here before. > >> > > >> > From a js release 'size' perspective, I don't think it matters > >>whether we > >> > use constants or liteterals, I think the main difference is that if > >>the > >> > static const exists it will also be included in the release output as > >>I > >> > expect it has an @export annotation. This means it should be > >> 'reflectable' > >> > via array/bracket access syntax via its original package/class naming. > >> But > >> > in terms of usage sites within the codebase, it should already be > >> optimised > >> > via GCC, becuase GCC is already capable of inlining anything annotated > >> as a > >> > constant [1]. > >> > So I would expect it to already be inlined in the js-release, and we > >> > *should not need* to write any code in the jx compiler to do that, > >>unless > >> > we specifically need this inlining (for some reason) in the debug > >>version > >> > of the js output. > >> > > >> > GCC also creates a single short named variable to refer to repeated > >> > literals througout the compiled codebase, so I would expect the > >>inlining > >> of > >> > consts would get this as a 2nd optimization pass as well. In the end I > >> > expect the only output difference between the two approaches should be > >> that > >> > we also get an extra exported constant that retains the same naming > >> > convention of lookups etc because we are @export-ing it. > >> > > >> > I'm pretty sure this is correct, but I might be wrong. I will check > >>all > >> > this later today, and report back. > >> > > >> > 1. > >> > > >>https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fgithub.c > >>om%2Fgoogle%2Fclosure-compiler%2Fwiki%2F&data=02% > 7C01%7C%7Cb1383499ae944d > >>36cc6808d4c8b34fc5%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636354119 > >>847040656&sdata=1J07jc05ULQcd8VP01X2D4b6B62UHc > EDTA71CS51O3s%3D&reserved=0 > >> Annotating-JavaScript-for-the-Closure-Compiler#const-const-type > >> > > >> > > >> > > >> > On Wed, Jul 12, 2017 at 3:47 AM, Harbs <harbs.li...@gmail.com> wrote: > >> > > >> >> +1. > >> >> > >> >> I also think that we have bigger fish to fry first. > >> >> > >> >> My point was not to force one way or the other. Rather that the way > >>it > >> >> currently stands there’s a valid reason to use string literals. I was > >> not > >> >> suggesting changing anything. > >> >> > >> >> Thanks, > >> >> Harbs > >> >> > >> >>> On Jul 11, 2017, at 6:33 PM, Josh Tynjala <joshtynj...@gmail.com> > >> wrote: > >> >>> > >> >>> That sounds like the proper way to handle this! We should be able to > >> >>> reference constants in our ActionScript so that we can get > >>compile-time > >> >>> errors from typos, while the compiler makes sure that generated > >> >> JavaScript > >> >>> can be properly minified. > >> >>> > >> >>> - Josh > >> >>> > >> >>> On Tue, Jul 11, 2017 at 8:20 AM, Alex Harui > >><aha...@adobe.com.invalid> > >> >>> wrote: > >> >>> > >> >>>> AIUI, there is a cost in the minified JS to using constants. > >> >>>> > >> >>>> However, there is a cost to screwing up the typing of a string > >>literal > >> >> as > >> >>>> well. > >> >>>> > >> >>>> The best answer for now, IMO, is to not care whether folks use > >> constants > >> >>>> or string literals. There are much bigger fish to fry. I don't > >>want > >> to > >> >>>> see sweeping changes of replacing all string literals with > >>constants > >> or > >> >>>> vice versa. If you've got that kind of time on your hands, learn > >>the > >> >>>> compiler code and see if you can make the cross-compiler replace > >>all > >> >>>> constants with string literals. IMO, that's the right answer. > >> >>>> > >> >>>> -Alex > >> >>>> > >> >>>> On 7/11/17, 5:37 AM, "Harbs" <harbs.li...@gmail.com> wrote: > >> >>>> > >> >>>>> Here’s what is output in the minimized code: > >> >>>>> > >> >>>>> function > >> >>>>> fqa(){}w('org.apache.flex.net.HTTPConstants.GET','GET'); > >> >>>> w('org.apache.flex > >> >>>>> .net.HTTPConstants.POST','POST');w('org.apache.flex.net. > >> >>>> HTTPConstants.PUT' > >> >>>>> ,'PUT');w('org.apache.flex.net.HTTPConstants.FORM_URL_ > >> >>>> ENCODED',Fm);w('org. > >> >>>>> apache.flex.net.HTTPConstants.DELETE','DELETE' > >> >>>> );w('org.apache.flex.net.HTT > >> >>>>> PConstants.OPEN','open');w('org.apache.flex.net. > >> >>>> HTTPConstants.COMPLETE',Bt > >> >>>>> );w('org.apache.flex.net.HTTPConstants.COMMUNICATION_ > >> >>>> ERROR',At);w('org.apa > >> >>>>> che.flex.net.HTTPConstants.IO_ERROR','ioError'); > >> >>>>> w('org.apache.flex.net.HTTPConstants.SECURITY_ERROR', > >> >>>> 'securityError');w('o > >> >>>>> rg.apache.flex.net.HTTPConstants.STATUS',Fx);w(' > >> >>>> org.apache.flex.net.HTTPCo > >> >>>>> nstants.RESPONSE_STATUS','httpResponseStatus');fqa. > >> >>>> prototype.h={names:[{na > >> >>>>> me:'HTTPConstants',i:IF,kind:g}]};w(IF,fqa); > >> >>>>> > >> >>>>> elsewhere: > >> >>>>> IF='org.apache.flex.net.HTTPConstants’, > >> >>>>> > >> >>>>> That’s 807 bytes. That’s quite a penalty for avoiding typing > >>“POST”… > >> >>>>> > >> >>>>> No idea what wiki you are referring to. > >> >>>>> > >> >>>>> Harbs > >> >>>>> > >> >>>>>> On Jul 11, 2017, at 2:36 PM, Justin Mclean < > >> jus...@classsoftware.com> > >> >>>>>> wrote: > >> >>>>>> > >> >>>>>> Hi, > >> >>>>>> > >> >>>>>>> As it stands now, use of constants result in more JS code after > >> >>>>>>> compiled. > >> >>>>>> > >> >>>>>> Debug yes but not optimised / release. > >> >>>>>> > >> >>>>>>> It’s possible that this can be optimized, but currently the most > >> >>>>>>> efficient JS code is produced if using string literals rather > >>than > >> >>>>>>> constants. (The Google compiler created variables for string > >> literals > >> >>>>>>> used more than once.) > >> >>>>>> > >> >>>>>> That's not we found in a previous thread on this list, the google > >> >>>>>> compiler optimises the constants and there is no penalty in using > >> >> them. > >> >>>>>> You mind provide examples that show the above is the actually > >>case > >> and > >> >>>>>> document it on the wiki? > >> >>>>>> > >> >>>>>> My vote would be not the duplicate the strings everywhere and use > >> >>>>>> constants as there is no cost and increased safety. > >> >>>>>> > >> >>>>>> Thanks, > >> >>>>>> Justin > >> >>>>> > >> >>>> > >> >>>> > >> >> > >> >> > >> > >> > >
