Dynamic access (aka square bracket access) is used in data binding, but people use it for other things as well. The really hard case involves "string math" where you access something like foo[someValue + "label"]. It is hard to know that "enUSLabel" and "frFRLabel" should not be renamed.
And yes, modules will need to find APIs in other modules or the host and renaming is a problem there too. But I'll bet that only a small fraction of APIs should not be renamed in any typical app, especially if no modules are in play. The question is "which ones"? But if we can make it possible, it should be a good obfuscator as well. My 2 cents, -Alex On 8/6/17, 10:57 PM, "Harbs" <harbs.li...@gmail.com> wrote: >I’m fuzzy on all the reasons for using @import so much. > >We’ve had discussions on the topic, but hey were spread out. > >The reasons that stick in my mind was for bracketed access (needed for >binding?) and reflection. Another reason I think that was mentioned was >for modules (which we don't’ yet really have a way to use). > >Is that it? > >> On Aug 7, 2017, at 8:34 AM, Alex Harui <aha...@adobe.com.INVALID> wrote: >> >> It might be more interesting and fruitful to investigate removing >>@export >> annotations. How could we determine which variables are being accessed >> via foo[someProperty] and only keep @export on those properties? >> >> You might be able to use a text replacement tool to remove @export and >> mess around with the rest of the source to prevent renaming of the few >> variables that will be looked up by foo[someProperty]. Either keeping >>the >> @export or use ["string"] access which I think prevents renaming in GCC. >> >> There are options in the compiler to skip generating the js-debug and >>just >> call GCC. >> >> My 2 cents, >> -Alex >> >> On 8/6/17, 3:13 PM, "Harbs" <harbs.li...@gmail.com> wrote: >> >>> I’m getting close to the release of my app and I’m starting to think >>> about some things related. >>> >>> I would like to have the option for minified code to have package, >>>class >>> and members renamed at compile time. I have two reasons for this: >>> >>> 1. Obfuscation. As it stands, it’s pretty easy to take minified code >>>from >>> FlexJS and reconstruct the original code with the original structure >>>and >>> naming. Everything is @exported and easily readable. I’d like to have a >>> method to rename everything to something completely unintelligible. >>> >>> 2. Code size. I was not sure how much package paths would effect code >>> size, so I just did an experiment. I renamed every package path in my >>>app >>> to a much shorter version (i.e. org.apache.flex.core becomes fxc, >>>etc.) I >>> did not spend the time renaming class names or class member names. Just >>> shortening the package paths resulted in a reduction of 509KB to 505KB >>> after gzipping. (Prior to gzipping the reduction was 53 KB.) Class >>>names >>> and member names are a significant percentage of the remaining code, so >>> it stands to reason that renaming those will result in a further >>> reduction of code size. >>> >>> To be clear: obfuscation is a much bigger drive for me than code size. >>> Code size is just an added plus. >>> >>> I was thinking of ideas on how to accomplish this goal. >>> >>> One idea was to enable some kind of metadata (or comments) in the code >>> that the compiler could interpret to rewrite the names >>> >>> Another idea was some kind of mapping file that serves the same >>>purpose. >>> >>> This is something that should be enabled via a compiler option. >>> >>> The challenge would be with library code in a swc. Since it’s already >>> compiled to JS, it would be much harder to rename things unless it >>>would >>> work using find/replace. It seems to me that it would be more reliable >>>if >>> done while walking the tree and packages, classes and members could >>>each >>> be handled explicitly. >>> >>> Thoughts? >>> >>> Harbs >> >
