Calling get__ and set__ function instead of accessing properties makes for very ugly output. That's how the original output was before we switched to using object.defineProperties and getters and setters. I'd rather not go back. Simple things like:
Foo.someInt++ Become: Foo.set__someInt(Foo.get__someInt() + 1); Which requires some tricky code paths in the compiler. And Foo.someNumber = Math.random() + 10 + Foo.someOtherNumber Becomes: Foo.set__someNumber(Math.random() + 10 + Foo.get__someOtherNumber()); I will explore renaming options. The key thing should be that if you don't use bracket access in your code, the compiler should be able to detect uses of named properties in MXML and data binding and automatically build the list of properties. In theory, the compiler could also detect obj["someStringLiteral"] and also add that to the list. Harder/impossible would be catching what a variable could be in obj[someStringVariable]. So I suppose we'll eventually let folks add names to the list manually. 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. HTH, -Alex On 8/7/17, 8:05 AM, "Harbs" <harbs.li...@gmail.com> wrote: > >> On Aug 7, 2017, at 5:52 PM, Alex Harui <aha...@adobe.com.INVALID> wrote: >> >> GCC has some static flow analysis, so yes, they can detect unused >> functions, but I don't think it can detect bracket access to functions >>any >> better than bracket access to properties, both of which are allowed in >>AS >> and JS. > >Yes. I realize this. I’m having trouble envisioning a way of generalizing >automatic avoidance of @exporting. > >> FalconJX doesn't call GCC on the command line. It uses a Java API. I >> think I've seen APIs that are probably what the property map does. The >> question remain about how to determine what to put in the list. > >I was thinking of a hand-crafted list. goog can dump a list of all >properties and the list can be edited. > >> MXML does use dynamic/bracket access, but it should be putting the whole >> property name in the file. I have not investigated as to how GCC >>handles >> that and whether those strings are mapped to a variable and the MXML >>data >> array is updated with the variable, or if there is a way to tell GCC >>that >> once a string is seen anywhere, then don't rename anything using that >> string. But if you want higher levels of obfuscation then we would want >> to rename those properties as well, and potentially even tell data >>binding >> to use the new property name. > >Yes. Possibly. > >> I think it is all possible, it is just a matter of time and priorities. >> Are you thinking you can't deploy without better obfuscation? > >I don’t think I can deploy to the public without obfuscation. Our first >stage is to make it available to partners. That I think I can do without >obfuscation. > >My fallback is probably a script which will do find/replaces on the >minified code. It’ll probably be tedious to construct the script, but >doable. In the meantime, I’ve been examining my minified code for places >where the source can be better constructed to output better minified >code. That’s where the thought of using the set__ and get__ functions >came from. > >Harbs > >> >> -Alex >> >> On 8/7/17, 2:56 AM, "Harbs" <harbs.li...@gmail.com> wrote: >> >>> Yishay came across this post: >>> >>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackov >>>er >>> >>>flow.com%2Fquestions%2F10433716%2Fgoogle-closure-compilers-advanced-opti >>>mi >>> >>>zations-option&data=02%7C01%7C%7Cf34315ae09c24c6132e008d4dd7aa141%7Cfa7b >>>1b >>> >>>5a7b34438794aed2c178decee1%7C0%7C0%7C636376966140467607&sdata=IwqmGYan9F >>>hZ >>> drheOGOK78KS6pWSHyTKq2eWfILnjkM%3D&reserved=0 >>> >>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstacko >>>ve >>> >>>rflow.com%2Fquestions%2F10433716%2Fgoogle-closure-compilers-advanced-opt >>>im >>> >>>izations-option&data=02%7C01%7C%7Cf34315ae09c24c6132e008d4dd7aa141%7Cfa7 >>>b1 >>> >>>b5a7b34438794aed2c178decee1%7C0%7C0%7C636376966140467607&sdata=IwqmGYan9 >>>Fh >>> ZdrheOGOK78KS6pWSHyTKq2eWfILnjkM%3D&reserved=0> >>> >>> I wonder if there’s some way to use the property_map options to control >>> renaming. My guess is that it would only work if @export is not used. >>> >>> Related to this general topic: >>> >>> I realized that goog is much better at minifying functions than >>> properties. That makes sense because you can reliably point to >>>functions >>> using references. Referencing variables is not reliable because the >>> references can end up pointing to different values. >>> >>> Theoretically, getters and setters could be better for that. The >>>problem >>> is that goog treats the getters like variables. If the compiler would >>> rewrite getter and setter access to the underlying getter and setter >>> functions, goog could probably do a better job optimizing those. (i.e. >>> instead of foo.baz = “baz”, Falcon could write foo.set__baz(“baz”) and >>> var baz = foo.baz could become var baz = foo.get__baz()) >>> >>> Harbs >>> >>>> On Aug 7, 2017, at 9:56 AM, Harbs <harbs.li...@gmail.com> wrote: >>>> >>>> Another case which seems to need exports is any property used in MXML. >>>> >>>> It seems like the low hanging fruit would be to allow some kind of >>>> markup to specify classes which don’t need exports. >>>> >>>> Rewriting constants to literals is another one which should be pretty >>>> easy to solve. >>>> >>>>> On Aug 7, 2017, at 9:24 AM, Alex Harui <aha...@adobe.com.INVALID> >>>>> wrote: >>>>> >>>>> 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 >>>>>>> >>>>>> >>>>> >>>> >>> >> >
