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 > >>> > >> > >> > >
