Package, Class and Method renaming

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Package, Class and Method renaming

Harbs
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package, Class and Method renaming

Alex Harui-2
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" <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package, Class and Method renaming

Harbs
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 <[hidden email]> 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" <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package, Class and Method renaming

Alex Harui-2
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" <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package, Class and Method renaming

Harbs
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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package, Class and Method renaming

Harbs
Yishay came across this post:
https://stackoverflow.com/questions/10433716/google-closure-compilers-advanced-optimizations-option <https://stackoverflow.com/questions/10433716/google-closure-compilers-advanced-optimizations-option>

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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package, Class and Method renaming

Alex Harui-2
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.

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.

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.

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?

-Alex

On 8/7/17, 2:56 AM, "Harbs" <[hidden email]> wrote:

>Yishay came across this post:
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackover
>flow.com%2Fquestions%2F10433716%2Fgoogle-closure-compilers-advanced-optimi
>zations-option&data=02%7C01%7C%7Cf34315ae09c24c6132e008d4dd7aa141%7Cfa7b1b
>5a7b34438794aed2c178decee1%7C0%7C0%7C636376966140467607&sdata=IwqmGYan9FhZ
>drheOGOK78KS6pWSHyTKq2eWfILnjkM%3D&reserved=0
><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackove
>rflow.com%2Fquestions%2F10433716%2Fgoogle-closure-compilers-advanced-optim
>izations-option&data=02%7C01%7C%7Cf34315ae09c24c6132e008d4dd7aa141%7Cfa7b1
>b5a7b34438794aed2c178decee1%7C0%7C0%7C636376966140467607&sdata=IwqmGYan9Fh
>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 <[hidden email]> 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 <[hidden email]>
>>>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" <[hidden email]> 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 <[hidden email]>
>>>>>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" <[hidden email]> 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
>>>>>
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package, Class and Method renaming

Harbs

> On Aug 7, 2017, at 5:52 PM, Alex Harui <[hidden email]> 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" <[hidden email]> wrote:
>
>> Yishay came across this post:
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackover
>> flow.com%2Fquestions%2F10433716%2Fgoogle-closure-compilers-advanced-optimi
>> zations-option&data=02%7C01%7C%7Cf34315ae09c24c6132e008d4dd7aa141%7Cfa7b1b
>> 5a7b34438794aed2c178decee1%7C0%7C0%7C636376966140467607&sdata=IwqmGYan9FhZ
>> drheOGOK78KS6pWSHyTKq2eWfILnjkM%3D&reserved=0
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackove
>> rflow.com%2Fquestions%2F10433716%2Fgoogle-closure-compilers-advanced-optim
>> izations-option&data=02%7C01%7C%7Cf34315ae09c24c6132e008d4dd7aa141%7Cfa7b1
>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636376966140467607&sdata=IwqmGYan9Fh
>> 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 <[hidden email]> 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 <[hidden email]>
>>>> 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" <[hidden email]> 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 <[hidden email]>
>>>>>> 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" <[hidden email]> 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
>>>>>>
>>>>>
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package, Class and Method renaming

Alex Harui-2
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" <[hidden email]> wrote:

>
>> On Aug 7, 2017, at 5:52 PM, Alex Harui <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>>> 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" <[hidden email]> 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 <[hidden email]>
>>>>>>> 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" <[hidden email]> 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package, Class and Method renaming

Harbs
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 <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package, Class and Method renaming

Alex Harui-2
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" <[hidden email]> 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 <[hidden email]> 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.
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package, Class and Method renaming

Alex Harui-2
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" <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
>>>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.
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package, Class and Method renaming

Greg Dove
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 <[hidden email]> 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" <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
> >>>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.
> >>
> >
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package, Class and Method renaming

Greg Dove
I guess that might help with the code minification, but it may be
irrelevant with the longer original strings with something like gzip
compression already.... there are so many levels to this.


On Wed, Aug 9, 2017 at 9:12 AM, Greg Dove <[hidden email]> 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 <[hidden email]>
> 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" <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
>> >>>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.
>> >>
>> >
>>
>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package, Class and Method renaming

Harbs
In reply to this post by Alex Harui-2
Did you try MXML with custom components? I’m not sure I understand how that would work.

> On Aug 9, 2017, at 12:01 AM, Alex Harui <[hidden email]> wrote:
>
> 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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package, Class and Method renaming

Alex Harui-2
I just tried DataBindingExample.  MyInitialView is essentially a custom
component.  What are you thinking won't work?

-Alex

On 8/8/17, 2:30 PM, "Harbs" <[hidden email]> wrote:

>Did you try MXML with custom components? I’m not sure I understand how
>that would work.
>
>> On Aug 9, 2017, at 12:01 AM, Alex Harui <[hidden email]>
>>wrote:
>>
>> 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.
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package, Class and Method renaming

Alex Harui-2
In reply to this post by Greg Dove
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" <[hidden email]> 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 <[hidden email]>
>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" <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
>> >>>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.
>> >>
>> >
>>
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package, Class and Method renaming

Harbs
In reply to this post by Alex Harui-2
I have a custom component “A” which implements a DisabledBead in ActionScript. It has a getter called “enabled”.

I have another MXML file “B” which uses the component and specifies enabled=“false”.

I’m assuming the “enabled” property in “A” will be renamed without an @export.

The mxml in “B” will still be using a string for the property name which will be “enabled” that will be undefined.

> On Aug 9, 2017, at 7:55 AM, Alex Harui <[hidden email]> wrote:
>
> I just tried DataBindingExample.  MyInitialView is essentially a custom
> component.  What are you thinking won't work?
>
> -Alex
>
> On 8/8/17, 2:30 PM, "Harbs" <[hidden email]> wrote:
>
>> Did you try MXML with custom components? I’m not sure I understand how
>> that would work.
>>
>>> On Aug 9, 2017, at 12:01 AM, Alex Harui <[hidden email]>
>>> wrote:
>>>
>>> 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.
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package, Class and Method renaming

Alex Harui-2
I don't think getters and setters get renamed because they are keys in the
Object.defineProperties data structure.  I'm wondering if that will be
enough obfuscation for you or not.

-Alex

On 8/8/17, 10:22 PM, "Harbs" <[hidden email]> wrote:

>I have a custom component “A” which implements a DisabledBead in
>ActionScript. It has a getter called “enabled”.
>
>I have another MXML file “B” which uses the component and specifies
>enabled=“false”.
>
>I’m assuming the “enabled” property in “A” will be renamed without an
>@export.
>
>The mxml in “B” will still be using a string for the property name which
>will be “enabled” that will be undefined.
>
>> On Aug 9, 2017, at 7:55 AM, Alex Harui <[hidden email]> wrote:
>>
>> I just tried DataBindingExample.  MyInitialView is essentially a custom
>> component.  What are you thinking won't work?
>>
>> -Alex
>>
>> On 8/8/17, 2:30 PM, "Harbs" <[hidden email]> wrote:
>>
>>> Did you try MXML with custom components? I’m not sure I understand how
>>> that would work.
>>>
>>>> On Aug 9, 2017, at 12:01 AM, Alex Harui <[hidden email]>
>>>> wrote:
>>>>
>>>> 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.
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Package, Class and Method renaming

Harbs
I’ll give it a go and see.

> On Aug 9, 2017, at 8:31 AM, Alex Harui <[hidden email]> wrote:
>
> I don't think getters and setters get renamed because they are keys in the
> Object.defineProperties data structure.  I'm wondering if that will be
> enough obfuscation for you or not.
>
> -Alex
>
> On 8/8/17, 10:22 PM, "Harbs" <[hidden email]> wrote:
>
>> I have a custom component “A” which implements a DisabledBead in
>> ActionScript. It has a getter called “enabled”.
>>
>> I have another MXML file “B” which uses the component and specifies
>> enabled=“false”.
>>
>> I’m assuming the “enabled” property in “A” will be renamed without an
>> @export.
>>
>> The mxml in “B” will still be using a string for the property name which
>> will be “enabled” that will be undefined.
>>
>>> On Aug 9, 2017, at 7:55 AM, Alex Harui <[hidden email]> wrote:
>>>
>>> I just tried DataBindingExample.  MyInitialView is essentially a custom
>>> component.  What are you thinking won't work?
>>>
>>> -Alex
>>>
>>> On 8/8/17, 2:30 PM, "Harbs" <[hidden email]> wrote:
>>>
>>>> Did you try MXML with custom components? I’m not sure I understand how
>>>> that would work.
>>>>
>>>>> On Aug 9, 2017, at 12:01 AM, Alex Harui <[hidden email]>
>>>>> wrote:
>>>>>
>>>>> 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.
>>>>
>>>
>>
>

12
Loading...