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%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636354119 >>847040656&sdata=1J07jc05ULQcd8VP01X2D4b6B62UHcEDTA71CS51O3s%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 >> >>>>> >> >>>> >> >>>> >> >> >> >> >> >>
