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://github.com/google/closure-compiler/wiki/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 >>>>> >>>> >>>> >> >>
