Interesting. Feel free to try it and see. I'm wondering where we use the class strings in FLEXJS_CLASS_INFO. Maybe they can be taken out.
-Alex On 8/8/17, 2:12 PM, "Greg Dove" <greg.d...@gmail.com> wrote: >Alex fyi I have wondered about breaking the class strings into literal >concatenation expressions with package parts for CLASS_INFO and in the >reflection data. This should end up minifying via closure compiler much >better, I think. >e.g. > >'org.'+'apache.'+'flex.'+'events.'+'Event' > > > > >On Wed, Aug 9, 2017 at 9:01 AM, Alex Harui <aha...@adobe.com.invalid> >wrote: > >> So I just pushed a first crack at suppressing most @export statements. >> Set -export-public-symbols=false and many @export statements should go >> away. The before size of TLFEditTestFlexJS was 813493 bytes. I >> recompiled TLF without @export symbols and the after size was 679609 >> bytes. And it ran. >> >> Some things I found were that MXML isn't a problem because the id maps >>to >> a getter/setter which maps to Object.DefineProperty which takes an >>object >> structure where the ids are keys so they don't get renamed. I noticed >> that class names take up a lot of strings because they are used as a >> literal in the FLEXJS_CLASS_INFO and thus never get minified/renamed. >> >> Anyway, try compiling and running your application code with this option >> set to false and see if it obfuscates things enough or not, and whether >> the result still runs. >> >> Thanks, >> -Alex >> >> On 8/7/17, 9:06 AM, "Alex Harui" <aha...@adobe.com.INVALID> wrote: >> >> >From the output side, it probably isn't hard, but there is no way >>succinct >> >way to tell the compiler which classes should use @export or not. You >> >could annotate the class definitions, but then you can't choose to >>output >> >@export without changing source. >> > >> >Why do you think we need per-class control over this output? >> > >> >-Alex >> > >> >On 8/7/17, 8:54 AM, "Harbs" <harbs.li...@gmail.com> wrote: >> > >> >>Cool. >> >> >> >>How difficult would it be to allow this on a class-by-class basis? >> >> >> >>> On Aug 7, 2017, at 6:35 PM, Alex Harui <aha...@adobe.com.INVALID> >> >>>wrote: >> >>> >> >>> First thing I will do, though, is allow turning off @export output >>on >> >>> entire compiler sessions. That might allow you to have your text >> >>>engine >> >>> and your application logic more aggressively renamed but not >>require us >> >>>to >> >>> fix code in other SWCs that might use bracket access. >> >> >> > >> >>