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