flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com.INVALID>
Subject Re: Package, Class and Method renaming
Date Mon, 07 Aug 2017 15:35:24 GMT
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.set__someInt(Foo.get__someInt() + 1);

Which requires some tricky code paths in the compiler.  And

Foo.someNumber = Math.random() + 10 + Foo.someOtherNumber


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.


On 8/7/17, 8:05 AM, "Harbs" <harbs.lists@gmail.com> wrote:

>> On Aug 7, 2017, at 5:52 PM, Alex Harui <aharui@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
>> better than bracket access to properties, both of which are allowed in
>> 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
>> that and whether those strings are mapped to a variable and the MXML
>> array is updated with the variable, or if there is a way to tell GCC
>> 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
>> 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
>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.
>> -Alex
>> On 8/7/17, 2:56 AM, "Harbs" <harbs.lists@gmail.com> wrote:
>>> Yishay came across this post:
>>> drheOGOK78KS6pWSHyTKq2eWfILnjkM%3D&reserved=0
>>> 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
>>> 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
>>> 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.lists@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 <aharui@adobe.com.INVALID>
>>>>> wrote:
>>>>> Dynamic access (aka square bracket access) is used in data binding,
>>>>> people use it for other things as well.  The really hard case
>>>>> "string math" where you access something like foo[someValue +
>>>>> 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
>>>>> "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.lists@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
>>>>>> 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 <aharui@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
>>>>>>> few
>>>>>>> variables that will be looked up by foo[someProperty].  Either
>>>>>>> keeping
>>>>>>> the
>>>>>>> @export or use ["string"] access which I think prevents renaming
>>>>>>> GCC.
>>>>>>> There are options in the compiler to skip generating the js-debug
>>>>>>> just
>>>>>>> call GCC.
>>>>>>> My 2 cents,
>>>>>>> -Alex
>>>>>>> On 8/6/17, 3:13 PM, "Harbs" <harbs.lists@gmail.com> wrote:
>>>>>>>> I’m getting close to the release of my app and I’m starting
>>>>>>>> about some things related.
>>>>>>>> I would like to have the option for minified code to have
>>>>>>>> class
>>>>>>>> and members renamed at compile time. I have two reasons for
>>>>>>>> 1. Obfuscation. As it stands, it’s pretty easy to take
>>>>>>>> from
>>>>>>>> FlexJS and reconstruct the original code with the original
>>>>>>>> and
>>>>>>>> naming. Everything is @exported and easily readable. I’d
like to
>>>>>>>> have a
>>>>>>>> method to rename everything to something completely
>>>>>>>> 2. Code size. I was not sure how much package paths would
>>>>>>>> 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
>>>>>>>> etc.) I
>>>>>>>> did not spend the time renaming class names or class member
>>>>>>>> Just
>>>>>>>> shortening the package paths resulted in a reduction of 509KB
>>>>>>>> 505KB
>>>>>>>> after gzipping. (Prior to gzipping the reduction was 53 KB.)
>>>>>>>> names
>>>>>>>> and member names are a significant percentage of the remaining
>>>>>>>> code, so
>>>>>>>> it stands to reason that renaming those will result in a
>>>>>>>> reduction of code size.
>>>>>>>> To be clear: obfuscation is a much bigger drive for me than
>>>>>>>> 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
>>>>>>>> purpose.
>>>>>>>> This is something that should be enabled via a compiler option.
>>>>>>>> The challenge would be with library code in a swc. Since
>>>>>>>> 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
>>>>>>>> reliable
>>>>>>>> if
>>>>>>>> done while walking the tree and packages, classes and members
>>>>>>>> each
>>>>>>>> be handled explicitly.
>>>>>>>> Thoughts?
>>>>>>>> Harbs

View raw message