You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Harbs <ha...@gmail.com> on 2017/08/06 22:13:45 UTC
Package, Class and Method renaming
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
Re: Package, Class and Method renaming
Posted by piotrz <pi...@gmail.com>.
TextField has already this bead, so there is no need to add it. If TextField
look bad once you run app without it - that would be a bug - maybe similar
to menu where you had to add UpgradeElement after "beadsAdded".
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Package-Class-and-Method-renaming-tp63702p63785.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: Package, Class and Method renaming
Posted by Harbs <ha...@gmail.com>.
It’s used elsewhere in MXML and it works just fine.
The whole component which has this subcomponent is added at runtime which is why I think the UpgradeElement bead was necessary.
The only issue I ran into was with the renaming when using the new option for leaving out @exports.
> On Aug 9, 2017, at 10:45 AM, piotrz <pi...@gmail.com> wrote:
>
> Harbs,
>
> Questions out of scope of your problem:
> 1) Is this whole component is created dynamically ? I mean new
> MyComponent()?
> 2) MDL TextField has UpgradeElement and you are adding it in MXML - didn't
> you get upgrade? Something went wrong?
>
> Piotr
>
>
>
> -----
> Apache Flex PMC
> piotrzarzycki21@gmail.com
> --
> View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Package-Class-and-Method-renaming-tp63702p63783.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: Package, Class and Method renaming
Posted by piotrz <pi...@gmail.com>.
Harbs,
Questions out of scope of your problem:
1) Is this whole component is created dynamically ? I mean new
MyComponent()?
2) MDL TextField has UpgradeElement and you are adding it in MXML - didn't
you get upgrade? Something went wrong?
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Package-Class-and-Method-renaming-tp63702p63783.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: Package, Class and Method renaming
Posted by Harbs <ha...@gmail.com>.
Thanks for working on this!
I’m going camping with my family this week, so I’m not sure I’m going to be able to test this until the end of the week or next week.
Thanks,
Harbs
> On Aug 12, 2017, at 7:13 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> I'm not sure I understand your proposal, but FWIW, I believe I have found
> one way to control renaming of getters and setters. I just pushed changes
> that collect property names used by MXML and data binding. Those
> properties are set as properties on Object.prototype in a custom externs
> file and that prevents GCC from renaming those properties in the
> getter/setter structures for Object.defineProperties.
>
> So, we could do more experiments with turning off @export for more SWCs
> and see if we can tell when we need to prevent their renaming and generate
> the fake externs to prevent their renaming, but I'm about to see if I can
> get a true non-unloadable module to work and it will need the thing that
> loads the module to not have renamed variables.
>
> Anyway, these changes should allow any getters and setters that aren't
> used by MXML and data binding to be renamed. So see if that causes
> sufficient obfuscation for you. And then see if it actually runs. I was
> sure I'd seen that references from non-getter/setters to getters were
> sometimes being given different names, but maybe that is no longer true
> now that the actual code for getters and setters are all in prototype
> methods.
>
> HTH,
> Alex
>
> On 8/10/17, 10:03 AM, "Harbs" <ha...@gmail.com> wrote:
>
>> Is there some way we can declare MXML differently so GCC can know that
>> we’re using properties? Maybe instead of strings we can use object
>> literals with proper references?
>>
>>> On Aug 10, 2017, at 6:39 PM, Alex Harui <ah...@adobe.com.INVALID>
>>> wrote:
>>>
>>> FWIW, I found out that some of that savings is because when something no
>>> longer has @export, it is eligible for dead code removal. That's sort
>>> of
>>> good, except that GCC's dead code removal can't detect usage from MXML
>>> and
>>> data binding so it removed stuff it shouldn't. The main SWCs may have
>>> to
>>> always export everything for cross-module usage.
>>>
>>> Of course, I could be wrong...
>>> -Alex
>>>
>>> On 8/10/17, 1:45 AM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>>> For kicks I tried modifying the compiler to not emit @export for my
>>>> code
>>>> (it still has the @exports for SDK code).
>>>>
>>>> The result on code size was more than 50KB smaller AFTER gzipping.
>>>> That’s
>>>> a reduction of more than 10%. Pretty significant. That’s without any
>>>> class renaming.
>>>>
>>>> Anyway, it blew up my app on properties that were used in data binding
>>>> in
>>>> MXML. I didn’t fix that to see the next place it blew up.
>>>>
>>>> If we go this route, we probably need to make MXML output smarter…
>>>>
>>>>> On Aug 10, 2017, at 12:31 AM, Alex Harui <ah...@adobe.com.INVALID>
>>>>> wrote:
>>>>>
>>>>> I've seen GCC not track renames before. The Object.defineProperty is
>>>>> just
>>>>> a data structure and doesn't add to the set of APIs for a class
>>>>> definition.
>>>>>
>>>>> I just realized that the class names are used by SimpleCSSValuesImpl
>>>>> to
>>>>> determine the type selectors. So if you rename those strings you will
>>>>> have to change your CSS.
>>>>>
>>>>> Also, I have not removed the exportSymbol calls on each class yet. I
>>>>> will
>>>>> try that as well.
>>>>>
>>>>> -Alex
>>>>>
>>>>>
>>>>> On 8/9/17, 2:11 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>> On Aug 9, 2017, at 11:56 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>>>>> wrote:
>>>>>>>
>>>>>>> The change I just made should only be for MXML. But I think I saw
>>>>>>> that
>>>>>>> I
>>>>>>> never did remove the @export for getters and setters in AS.
>>>>>>> However,
>>>>>>> doing so would probably break MXML setting of those properties.
>>>>>>>
>>>>>>> I don't think you can tell when compiling a SWC which properties
>>>>>>> someone
>>>>>>> is going to use from MXML, so I'm not sure passing through @export
>>>>>>> or
>>>>>>> somehow marking certain APIs as "don't rename" is going to be
>>>>>>> useful.
>>>>>>
>>>>>> It would be useful for client code because I do know which properties
>>>>>> my
>>>>>> MXML will use.
>>>>>>
>>>>>>> On
>>>>>>> the other hand, MXML does know every property that you accessed from
>>>>>>> MXML
>>>>>>> so maybe that's what I'll try next. I think I see an API in GCC
>>>>>>> where
>>>>>>> you
>>>>>>> can tell it things that shouldn't be renamed.
>>>>>>
>>>>>> That sounds interesting.
>>>>>>
>>>>>>> IMO, this is a bug or missing capability in GCC. They don't see
>>>>>>> Object.defineProperties as part of the class definition so they
>>>>>>> don't
>>>>>>> track the renames properly. So, removing @exports from getters in
>>>>>>> AS
>>>>>>> may
>>>>>>> also just fail in calls from other AS classes.
>>>>>>
>>>>>> I lost you. Where did you see that GCC doesn’t track the definitions?
>>>>>>
>>>>>>> Regarding obfuscation, if we have to export getters, is that really
>>>>>>> exposing important secrets?
>>>>>>
>>>>>> Not sure, but I’d like to keep the code as difficult to follow as
>>>>>> possible.
>>>>>>
>>>>>>> The actual code for a getter/setter is
>>>>>>> elsewhere in the output file. It might be possible to do string
>>>>>>> replacement on the exported names after the minification.
>>>>>>
>>>>>> String replacement is definitely an option if it comes to that. I’m
>>>>>> probably going to do that for class names and paths as I don’t really
>>>>>> see
>>>>>> that we currently have a solution for that.
>>>>>>
>>>>>>> Thoughts?
>>>>>>> -Alex
>>>>>>>
>>>>>>> On 8/9/17, 1:24 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>>
>>>>>>>> I just compiled with the new option and it appears to work. Yay. On
>>>>>>>> the
>>>>>>>> other hand, only functions and variables are being minified.
>>>>>>>> getters
>>>>>>>> and
>>>>>>>> setters (which is a very large percentage of the signature of my
>>>>>>>> code)
>>>>>>>> is
>>>>>>>> not.
>>>>>>>>
>>>>>>>> It looks like that adds the @exports for non-mxml files as well.
>>>>>>>> Can
>>>>>>>> we
>>>>>>>> output the @exports for only MXML declared variables?
>>>>>>>>
>>>>>>>> If a comment with @export is added in AS code, will that be passed
>>>>>>>> through to the JS output?
>>>>>>>>
>>>>>>>> If yes, I think @exporting ids declared in MXML should be the only
>>>>>>>> case
>>>>>>>> we need. I can probably handle any specific cases where that might
>>>>>>>> break
>>>>>>>> output code by manually inserting @export statements.
>>>>>>>>
>>>>>>>>> On Aug 9, 2017, at 10:20 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hmm. I thought GCC didn't rename those. Anyway, I added back the
>>>>>>>>> @export. See if that works for you and then see if you think
>>>>>>>>> there
>>>>>>>>> is
>>>>>>>>> enough obfuscation.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> -Alex
>>>>>>>>>
>>>>>>>>> On 8/9/17, 12:45 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> The problem is as follows:
>>>>>>>>>>
>>>>>>>>>> Taking textInput as an example, the MXML gets compiled into the
>>>>>>>>>> following:
>>>>>>>>>> textInput: {
>>>>>>>>>> /** @this {com.printui.view.components.PaletteSlider} */
>>>>>>>>>> get: function() {
>>>>>>>>>> return this.textInput_;
>>>>>>>>>> },
>>>>>>>>>> /** @this {com.printui.view.components.PaletteSlider} */
>>>>>>>>>> set: function(value) {
>>>>>>>>>> if (value != this.textInput_) {
>>>>>>>>>> this.textInput_ = value;
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> this.dispatchEvent(org.apache.flex.events.ValueChangeEvent.createU
>>>>>>>>>> pd
>>>>>>>>>> at
>>>>>>>>>> eE
>>>>>>>>>> ve
>>>>>>>>>> nt(this, 'textInput', null, value));
>>>>>>>>>> }
>>>>>>>>>> }
>>>>>>>>>> },
>>>>>>>>>>
>>>>>>>>>> which gets minified to this:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> yw:{get:r('Nja'),set:function(a){a!=this.Nja&&(this.Nja=a,this.dis
>>>>>>>>>> pa
>>>>>>>>>> tc
>>>>>>>>>> hE
>>>>>>>>>> ve
>>>>>>>>>> nt(yR(this,iI,null,a)))}}
>>>>>>>>>>
>>>>>>>>>> goog has no way of knowing that the original textInput property
>>>>>>>>>> name
>>>>>>>>>> is
>>>>>>>>>> used anywhere so all references to textInput are changed to yw.
>>>>>>>>>>
>>>>>>>>>> I think the solution to this is to add @export tags to the
>>>>>>>>>> Object.defineProperty specification for any property that’s
>>>>>>>>>> declared
>>>>>>>>>> or
>>>>>>>>>> used in the MXML.
>>>>>>>>>>
>>>>>>>>>> If localId is used, there might be another option which would be
>>>>>>>>>> to
>>>>>>>>>> rename the id to some value that’s one or two characters long.
>>>>>>>>>> I’m
>>>>>>>>>> pretty
>>>>>>>>>> sure that goog will not rename really short property names like
>>>>>>>>>> that.
>>>>>>>>>> (We
>>>>>>>>>> can’t do that for id because it might be used by CSS.)
>>>>>>>>>>
>>>>>>>>>> Harbs
>>>>>>>>>>
>>>>>>>>>>> On Aug 9, 2017, at 10:25 AM, Harbs <ha...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Here’s a problem I ran into:
>>>>>>>>>>>
>>>>>>>>>>> I have a component which has the following:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>>>>>> pa
>>>>>>>>>>> st
>>>>>>>>>>> e.
>>>>>>>>>>> ap
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99b
>>>>>>>>>>> b%
>>>>>>>>>>> 7C
>>>>>>>>>>> fa
>>>>>>>>>>> 7b
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=F
>>>>>>>>>>> Pa
>>>>>>>>>>> am
>>>>>>>>>>> WR
>>>>>>>>>>> Ac
>>>>>>>>>>> t5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>>>>>>>> Fp
>>>>>>>>>>> as
>>>>>>>>>>> te
>>>>>>>>>>> .a
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> pache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99
>>>>>>>>>>> bb
>>>>>>>>>>> %7
>>>>>>>>>>> Cf
>>>>>>>>>>> a7
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=
>>>>>>>>>>> FP
>>>>>>>>>>> aa
>>>>>>>>>>> mW
>>>>>>>>>>> RA
>>>>>>>>>>> ct5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0>
>>>>>>>>>>>
>>>>>>>>>>> In the script block I have references to disableBead, textInput,
>>>>>>>>>>> etc.
>>>>>>>>>>>
>>>>>>>>>>> The instance correctly has properties of disableBead, textInput,
>>>>>>>>>>> etc.,
>>>>>>>>>>> but every reference to these properties is renamed.
>>>>>>>>>>>
>>>>>>>>>>> textInput.addEventListener
>>>>>>>>>>> becomes:
>>>>>>>>>>> this.yw.addEventListener
>>>>>>>>>>>
>>>>>>>>>>> disableBead.disabled
>>>>>>>>>>> becomes
>>>>>>>>>>> this.Jm.disabled
>>>>>>>>>>>
>>>>>>>>>>> etc.
>>>>>>>>>>>
>>>>>>>>>>> this.yw and this.Jm are both undefined
>>>>>>>>>>>
>>>>>>>>>>>> On Aug 9, 2017, at 9:10 AM, Harbs <harbs.lists@gmail.com
>>>>>>>>>>>> <ma...@gmail.com>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I’ll give it a go and see.
>>>>>>>>>>>>
>>>>>>>>>>>>> On Aug 9, 2017, at 8:31 AM, Alex Harui
>>>>>>>>>>>>> <aharui@adobe.com.INVALID
>>>>>>>>>>>>> <ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com
>>>>>>>>>>>>> <ma...@gmail.com>> 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
>>>>>>>>>>>>>>> <aharui@adobe.com.INVALID
>>>>>>>>>>>>>>> <ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com
>>>>>>>>>>>>>>> <ma...@gmail.com>> 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
>>>>>>>>>>>>>>>>> <aharui@adobe.com.INVALID
>>>>>>>>>>>>>>>>> <ma...@adobe.com.INVALID>>
>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Package, Class and Method renaming
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I'm not sure I understand your proposal, but FWIW, I believe I have found
one way to control renaming of getters and setters. I just pushed changes
that collect property names used by MXML and data binding. Those
properties are set as properties on Object.prototype in a custom externs
file and that prevents GCC from renaming those properties in the
getter/setter structures for Object.defineProperties.
So, we could do more experiments with turning off @export for more SWCs
and see if we can tell when we need to prevent their renaming and generate
the fake externs to prevent their renaming, but I'm about to see if I can
get a true non-unloadable module to work and it will need the thing that
loads the module to not have renamed variables.
Anyway, these changes should allow any getters and setters that aren't
used by MXML and data binding to be renamed. So see if that causes
sufficient obfuscation for you. And then see if it actually runs. I was
sure I'd seen that references from non-getter/setters to getters were
sometimes being given different names, but maybe that is no longer true
now that the actual code for getters and setters are all in prototype
methods.
HTH,
Alex
On 8/10/17, 10:03 AM, "Harbs" <ha...@gmail.com> wrote:
>Is there some way we can declare MXML differently so GCC can know that
>we’re using properties? Maybe instead of strings we can use object
>literals with proper references?
>
>> On Aug 10, 2017, at 6:39 PM, Alex Harui <ah...@adobe.com.INVALID>
>>wrote:
>>
>> FWIW, I found out that some of that savings is because when something no
>> longer has @export, it is eligible for dead code removal. That's sort
>>of
>> good, except that GCC's dead code removal can't detect usage from MXML
>>and
>> data binding so it removed stuff it shouldn't. The main SWCs may have
>>to
>> always export everything for cross-module usage.
>>
>> Of course, I could be wrong...
>> -Alex
>>
>> On 8/10/17, 1:45 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>>> For kicks I tried modifying the compiler to not emit @export for my
>>>code
>>> (it still has the @exports for SDK code).
>>>
>>> The result on code size was more than 50KB smaller AFTER gzipping.
>>>That’s
>>> a reduction of more than 10%. Pretty significant. That’s without any
>>> class renaming.
>>>
>>> Anyway, it blew up my app on properties that were used in data binding
>>>in
>>> MXML. I didn’t fix that to see the next place it blew up.
>>>
>>> If we go this route, we probably need to make MXML output smarter…
>>>
>>>> On Aug 10, 2017, at 12:31 AM, Alex Harui <ah...@adobe.com.INVALID>
>>>> wrote:
>>>>
>>>> I've seen GCC not track renames before. The Object.defineProperty is
>>>> just
>>>> a data structure and doesn't add to the set of APIs for a class
>>>> definition.
>>>>
>>>> I just realized that the class names are used by SimpleCSSValuesImpl
>>>>to
>>>> determine the type selectors. So if you rename those strings you will
>>>> have to change your CSS.
>>>>
>>>> Also, I have not removed the exportSymbol calls on each class yet. I
>>>> will
>>>> try that as well.
>>>>
>>>> -Alex
>>>>
>>>>
>>>> On 8/9/17, 2:11 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>
>>>>>
>>>>>> On Aug 9, 2017, at 11:56 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>>>> wrote:
>>>>>>
>>>>>> The change I just made should only be for MXML. But I think I saw
>>>>>> that
>>>>>> I
>>>>>> never did remove the @export for getters and setters in AS.
>>>>>>However,
>>>>>> doing so would probably break MXML setting of those properties.
>>>>>>
>>>>>> I don't think you can tell when compiling a SWC which properties
>>>>>> someone
>>>>>> is going to use from MXML, so I'm not sure passing through @export
>>>>>>or
>>>>>> somehow marking certain APIs as "don't rename" is going to be
>>>>>>useful.
>>>>>
>>>>> It would be useful for client code because I do know which properties
>>>>> my
>>>>> MXML will use.
>>>>>
>>>>>> On
>>>>>> the other hand, MXML does know every property that you accessed from
>>>>>> MXML
>>>>>> so maybe that's what I'll try next. I think I see an API in GCC
>>>>>>where
>>>>>> you
>>>>>> can tell it things that shouldn't be renamed.
>>>>>
>>>>> That sounds interesting.
>>>>>
>>>>>> IMO, this is a bug or missing capability in GCC. They don't see
>>>>>> Object.defineProperties as part of the class definition so they
>>>>>>don't
>>>>>> track the renames properly. So, removing @exports from getters in
>>>>>>AS
>>>>>> may
>>>>>> also just fail in calls from other AS classes.
>>>>>
>>>>> I lost you. Where did you see that GCC doesn’t track the definitions?
>>>>>
>>>>>> Regarding obfuscation, if we have to export getters, is that really
>>>>>> exposing important secrets?
>>>>>
>>>>> Not sure, but I’d like to keep the code as difficult to follow as
>>>>> possible.
>>>>>
>>>>>> The actual code for a getter/setter is
>>>>>> elsewhere in the output file. It might be possible to do string
>>>>>> replacement on the exported names after the minification.
>>>>>
>>>>> String replacement is definitely an option if it comes to that. I’m
>>>>> probably going to do that for class names and paths as I don’t really
>>>>> see
>>>>> that we currently have a solution for that.
>>>>>
>>>>>> Thoughts?
>>>>>> -Alex
>>>>>>
>>>>>> On 8/9/17, 1:24 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>
>>>>>>> I just compiled with the new option and it appears to work. Yay. On
>>>>>>> the
>>>>>>> other hand, only functions and variables are being minified.
>>>>>>>getters
>>>>>>> and
>>>>>>> setters (which is a very large percentage of the signature of my
>>>>>>> code)
>>>>>>> is
>>>>>>> not.
>>>>>>>
>>>>>>> It looks like that adds the @exports for non-mxml files as well.
>>>>>>>Can
>>>>>>> we
>>>>>>> output the @exports for only MXML declared variables?
>>>>>>>
>>>>>>> If a comment with @export is added in AS code, will that be passed
>>>>>>> through to the JS output?
>>>>>>>
>>>>>>> If yes, I think @exporting ids declared in MXML should be the only
>>>>>>> case
>>>>>>> we need. I can probably handle any specific cases where that might
>>>>>>> break
>>>>>>> output code by manually inserting @export statements.
>>>>>>>
>>>>>>>> On Aug 9, 2017, at 10:20 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hmm. I thought GCC didn't rename those. Anyway, I added back the
>>>>>>>> @export. See if that works for you and then see if you think
>>>>>>>>there
>>>>>>>> is
>>>>>>>> enough obfuscation.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> -Alex
>>>>>>>>
>>>>>>>> On 8/9/17, 12:45 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> The problem is as follows:
>>>>>>>>>
>>>>>>>>> Taking textInput as an example, the MXML gets compiled into the
>>>>>>>>> following:
>>>>>>>>> textInput: {
>>>>>>>>> /** @this {com.printui.view.components.PaletteSlider} */
>>>>>>>>> get: function() {
>>>>>>>>> return this.textInput_;
>>>>>>>>> },
>>>>>>>>> /** @this {com.printui.view.components.PaletteSlider} */
>>>>>>>>> set: function(value) {
>>>>>>>>> if (value != this.textInput_) {
>>>>>>>>> this.textInput_ = value;
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>this.dispatchEvent(org.apache.flex.events.ValueChangeEvent.createU
>>>>>>>>>pd
>>>>>>>>> at
>>>>>>>>> eE
>>>>>>>>> ve
>>>>>>>>> nt(this, 'textInput', null, value));
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>> },
>>>>>>>>>
>>>>>>>>> which gets minified to this:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>yw:{get:r('Nja'),set:function(a){a!=this.Nja&&(this.Nja=a,this.dis
>>>>>>>>>pa
>>>>>>>>> tc
>>>>>>>>> hE
>>>>>>>>> ve
>>>>>>>>> nt(yR(this,iI,null,a)))}}
>>>>>>>>>
>>>>>>>>> goog has no way of knowing that the original textInput property
>>>>>>>>> name
>>>>>>>>> is
>>>>>>>>> used anywhere so all references to textInput are changed to yw.
>>>>>>>>>
>>>>>>>>> I think the solution to this is to add @export tags to the
>>>>>>>>> Object.defineProperty specification for any property that’s
>>>>>>>>> declared
>>>>>>>>> or
>>>>>>>>> used in the MXML.
>>>>>>>>>
>>>>>>>>> If localId is used, there might be another option which would be
>>>>>>>>>to
>>>>>>>>> rename the id to some value that’s one or two characters long.
>>>>>>>>>I’m
>>>>>>>>> pretty
>>>>>>>>> sure that goog will not rename really short property names like
>>>>>>>>> that.
>>>>>>>>> (We
>>>>>>>>> can’t do that for id because it might be used by CSS.)
>>>>>>>>>
>>>>>>>>> Harbs
>>>>>>>>>
>>>>>>>>>> On Aug 9, 2017, at 10:25 AM, Harbs <ha...@gmail.com>
>>>>>>>>>>wrote:
>>>>>>>>>>
>>>>>>>>>> Here’s a problem I ran into:
>>>>>>>>>>
>>>>>>>>>> I have a component which has the following:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>>>>>pa
>>>>>>>>>> st
>>>>>>>>>> e.
>>>>>>>>>> ap
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>ache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99b
>>>>>>>>>>b%
>>>>>>>>>> 7C
>>>>>>>>>> fa
>>>>>>>>>> 7b
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=F
>>>>>>>>>>Pa
>>>>>>>>>> am
>>>>>>>>>> WR
>>>>>>>>>> Ac
>>>>>>>>>> t5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>>>>>>>Fp
>>>>>>>>>> as
>>>>>>>>>> te
>>>>>>>>>> .a
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>pache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99
>>>>>>>>>>bb
>>>>>>>>>> %7
>>>>>>>>>> Cf
>>>>>>>>>> a7
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=
>>>>>>>>>>FP
>>>>>>>>>> aa
>>>>>>>>>> mW
>>>>>>>>>> RA
>>>>>>>>>> ct5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0>
>>>>>>>>>>
>>>>>>>>>> In the script block I have references to disableBead, textInput,
>>>>>>>>>> etc.
>>>>>>>>>>
>>>>>>>>>> The instance correctly has properties of disableBead, textInput,
>>>>>>>>>> etc.,
>>>>>>>>>> but every reference to these properties is renamed.
>>>>>>>>>>
>>>>>>>>>> textInput.addEventListener
>>>>>>>>>> becomes:
>>>>>>>>>> this.yw.addEventListener
>>>>>>>>>>
>>>>>>>>>> disableBead.disabled
>>>>>>>>>> becomes
>>>>>>>>>> this.Jm.disabled
>>>>>>>>>>
>>>>>>>>>> etc.
>>>>>>>>>>
>>>>>>>>>> this.yw and this.Jm are both undefined
>>>>>>>>>>
>>>>>>>>>>> On Aug 9, 2017, at 9:10 AM, Harbs <harbs.lists@gmail.com
>>>>>>>>>>> <ma...@gmail.com>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I’ll give it a go and see.
>>>>>>>>>>>
>>>>>>>>>>>> On Aug 9, 2017, at 8:31 AM, Alex Harui
>>>>>>>>>>>><aharui@adobe.com.INVALID
>>>>>>>>>>>> <ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com
>>>>>>>>>>>> <ma...@gmail.com>> 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
>>>>>>>>>>>>>> <aharui@adobe.com.INVALID
>>>>>>>>>>>>>> <ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com
>>>>>>>>>>>>>> <ma...@gmail.com>> 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
>>>>>>>>>>>>>>>> <aharui@adobe.com.INVALID
>>>>>>>>>>>>>>>> <ma...@adobe.com.INVALID>>
>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Package, Class and Method renaming
Posted by Harbs <ha...@gmail.com>.
Is there some way we can declare MXML differently so GCC can know that we’re using properties? Maybe instead of strings we can use object literals with proper references?
> On Aug 10, 2017, at 6:39 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> FWIW, I found out that some of that savings is because when something no
> longer has @export, it is eligible for dead code removal. That's sort of
> good, except that GCC's dead code removal can't detect usage from MXML and
> data binding so it removed stuff it shouldn't. The main SWCs may have to
> always export everything for cross-module usage.
>
> Of course, I could be wrong...
> -Alex
>
> On 8/10/17, 1:45 AM, "Harbs" <ha...@gmail.com> wrote:
>
>> For kicks I tried modifying the compiler to not emit @export for my code
>> (it still has the @exports for SDK code).
>>
>> The result on code size was more than 50KB smaller AFTER gzipping. That’s
>> a reduction of more than 10%. Pretty significant. That’s without any
>> class renaming.
>>
>> Anyway, it blew up my app on properties that were used in data binding in
>> MXML. I didn’t fix that to see the next place it blew up.
>>
>> If we go this route, we probably need to make MXML output smarter…
>>
>>> On Aug 10, 2017, at 12:31 AM, Alex Harui <ah...@adobe.com.INVALID>
>>> wrote:
>>>
>>> I've seen GCC not track renames before. The Object.defineProperty is
>>> just
>>> a data structure and doesn't add to the set of APIs for a class
>>> definition.
>>>
>>> I just realized that the class names are used by SimpleCSSValuesImpl to
>>> determine the type selectors. So if you rename those strings you will
>>> have to change your CSS.
>>>
>>> Also, I have not removed the exportSymbol calls on each class yet. I
>>> will
>>> try that as well.
>>>
>>> -Alex
>>>
>>>
>>> On 8/9/17, 2:11 PM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>>>
>>>>> On Aug 9, 2017, at 11:56 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>>> wrote:
>>>>>
>>>>> The change I just made should only be for MXML. But I think I saw
>>>>> that
>>>>> I
>>>>> never did remove the @export for getters and setters in AS. However,
>>>>> doing so would probably break MXML setting of those properties.
>>>>>
>>>>> I don't think you can tell when compiling a SWC which properties
>>>>> someone
>>>>> is going to use from MXML, so I'm not sure passing through @export or
>>>>> somehow marking certain APIs as "don't rename" is going to be useful.
>>>>
>>>> It would be useful for client code because I do know which properties
>>>> my
>>>> MXML will use.
>>>>
>>>>> On
>>>>> the other hand, MXML does know every property that you accessed from
>>>>> MXML
>>>>> so maybe that's what I'll try next. I think I see an API in GCC where
>>>>> you
>>>>> can tell it things that shouldn't be renamed.
>>>>
>>>> That sounds interesting.
>>>>
>>>>> IMO, this is a bug or missing capability in GCC. They don't see
>>>>> Object.defineProperties as part of the class definition so they don't
>>>>> track the renames properly. So, removing @exports from getters in AS
>>>>> may
>>>>> also just fail in calls from other AS classes.
>>>>
>>>> I lost you. Where did you see that GCC doesn’t track the definitions?
>>>>
>>>>> Regarding obfuscation, if we have to export getters, is that really
>>>>> exposing important secrets?
>>>>
>>>> Not sure, but I’d like to keep the code as difficult to follow as
>>>> possible.
>>>>
>>>>> The actual code for a getter/setter is
>>>>> elsewhere in the output file. It might be possible to do string
>>>>> replacement on the exported names after the minification.
>>>>
>>>> String replacement is definitely an option if it comes to that. I’m
>>>> probably going to do that for class names and paths as I don’t really
>>>> see
>>>> that we currently have a solution for that.
>>>>
>>>>> Thoughts?
>>>>> -Alex
>>>>>
>>>>> On 8/9/17, 1:24 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>>
>>>>>> I just compiled with the new option and it appears to work. Yay. On
>>>>>> the
>>>>>> other hand, only functions and variables are being minified. getters
>>>>>> and
>>>>>> setters (which is a very large percentage of the signature of my
>>>>>> code)
>>>>>> is
>>>>>> not.
>>>>>>
>>>>>> It looks like that adds the @exports for non-mxml files as well. Can
>>>>>> we
>>>>>> output the @exports for only MXML declared variables?
>>>>>>
>>>>>> If a comment with @export is added in AS code, will that be passed
>>>>>> through to the JS output?
>>>>>>
>>>>>> If yes, I think @exporting ids declared in MXML should be the only
>>>>>> case
>>>>>> we need. I can probably handle any specific cases where that might
>>>>>> break
>>>>>> output code by manually inserting @export statements.
>>>>>>
>>>>>>> On Aug 9, 2017, at 10:20 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hmm. I thought GCC didn't rename those. Anyway, I added back the
>>>>>>> @export. See if that works for you and then see if you think there
>>>>>>> is
>>>>>>> enough obfuscation.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> -Alex
>>>>>>>
>>>>>>> On 8/9/17, 12:45 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>>
>>>>>>>> The problem is as follows:
>>>>>>>>
>>>>>>>> Taking textInput as an example, the MXML gets compiled into the
>>>>>>>> following:
>>>>>>>> textInput: {
>>>>>>>> /** @this {com.printui.view.components.PaletteSlider} */
>>>>>>>> get: function() {
>>>>>>>> return this.textInput_;
>>>>>>>> },
>>>>>>>> /** @this {com.printui.view.components.PaletteSlider} */
>>>>>>>> set: function(value) {
>>>>>>>> if (value != this.textInput_) {
>>>>>>>> this.textInput_ = value;
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> this.dispatchEvent(org.apache.flex.events.ValueChangeEvent.createUpd
>>>>>>>> at
>>>>>>>> eE
>>>>>>>> ve
>>>>>>>> nt(this, 'textInput', null, value));
>>>>>>>> }
>>>>>>>> }
>>>>>>>> },
>>>>>>>>
>>>>>>>> which gets minified to this:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> yw:{get:r('Nja'),set:function(a){a!=this.Nja&&(this.Nja=a,this.dispa
>>>>>>>> tc
>>>>>>>> hE
>>>>>>>> ve
>>>>>>>> nt(yR(this,iI,null,a)))}}
>>>>>>>>
>>>>>>>> goog has no way of knowing that the original textInput property
>>>>>>>> name
>>>>>>>> is
>>>>>>>> used anywhere so all references to textInput are changed to yw.
>>>>>>>>
>>>>>>>> I think the solution to this is to add @export tags to the
>>>>>>>> Object.defineProperty specification for any property that’s
>>>>>>>> declared
>>>>>>>> or
>>>>>>>> used in the MXML.
>>>>>>>>
>>>>>>>> If localId is used, there might be another option which would be to
>>>>>>>> rename the id to some value that’s one or two characters long. I’m
>>>>>>>> pretty
>>>>>>>> sure that goog will not rename really short property names like
>>>>>>>> that.
>>>>>>>> (We
>>>>>>>> can’t do that for id because it might be used by CSS.)
>>>>>>>>
>>>>>>>> Harbs
>>>>>>>>
>>>>>>>>> On Aug 9, 2017, at 10:25 AM, Harbs <ha...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> Here’s a problem I ran into:
>>>>>>>>>
>>>>>>>>> I have a component which has the following:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa
>>>>>>>>> st
>>>>>>>>> e.
>>>>>>>>> ap
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99bb%
>>>>>>>>> 7C
>>>>>>>>> fa
>>>>>>>>> 7b
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=FPa
>>>>>>>>> am
>>>>>>>>> WR
>>>>>>>>> Ac
>>>>>>>>> t5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fp
>>>>>>>>> as
>>>>>>>>> te
>>>>>>>>> .a
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> pache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99bb
>>>>>>>>> %7
>>>>>>>>> Cf
>>>>>>>>> a7
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=FP
>>>>>>>>> aa
>>>>>>>>> mW
>>>>>>>>> RA
>>>>>>>>> ct5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0>
>>>>>>>>>
>>>>>>>>> In the script block I have references to disableBead, textInput,
>>>>>>>>> etc.
>>>>>>>>>
>>>>>>>>> The instance correctly has properties of disableBead, textInput,
>>>>>>>>> etc.,
>>>>>>>>> but every reference to these properties is renamed.
>>>>>>>>>
>>>>>>>>> textInput.addEventListener
>>>>>>>>> becomes:
>>>>>>>>> this.yw.addEventListener
>>>>>>>>>
>>>>>>>>> disableBead.disabled
>>>>>>>>> becomes
>>>>>>>>> this.Jm.disabled
>>>>>>>>>
>>>>>>>>> etc.
>>>>>>>>>
>>>>>>>>> this.yw and this.Jm are both undefined
>>>>>>>>>
>>>>>>>>>> On Aug 9, 2017, at 9:10 AM, Harbs <harbs.lists@gmail.com
>>>>>>>>>> <ma...@gmail.com>> wrote:
>>>>>>>>>>
>>>>>>>>>> I’ll give it a go and see.
>>>>>>>>>>
>>>>>>>>>>> On Aug 9, 2017, at 8:31 AM, Alex Harui <aharui@adobe.com.INVALID
>>>>>>>>>>> <ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com
>>>>>>>>>>> <ma...@gmail.com>> 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
>>>>>>>>>>>>> <aharui@adobe.com.INVALID
>>>>>>>>>>>>> <ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com
>>>>>>>>>>>>> <ma...@gmail.com>> 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
>>>>>>>>>>>>>>> <aharui@adobe.com.INVALID
>>>>>>>>>>>>>>> <ma...@adobe.com.INVALID>>
>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Package, Class and Method renaming
Posted by Alex Harui <ah...@adobe.com.INVALID>.
FWIW, I found out that some of that savings is because when something no
longer has @export, it is eligible for dead code removal. That's sort of
good, except that GCC's dead code removal can't detect usage from MXML and
data binding so it removed stuff it shouldn't. The main SWCs may have to
always export everything for cross-module usage.
Of course, I could be wrong...
-Alex
On 8/10/17, 1:45 AM, "Harbs" <ha...@gmail.com> wrote:
>For kicks I tried modifying the compiler to not emit @export for my code
>(it still has the @exports for SDK code).
>
>The result on code size was more than 50KB smaller AFTER gzipping. That’s
>a reduction of more than 10%. Pretty significant. That’s without any
>class renaming.
>
>Anyway, it blew up my app on properties that were used in data binding in
>MXML. I didn’t fix that to see the next place it blew up.
>
>If we go this route, we probably need to make MXML output smarter…
>
>> On Aug 10, 2017, at 12:31 AM, Alex Harui <ah...@adobe.com.INVALID>
>>wrote:
>>
>> I've seen GCC not track renames before. The Object.defineProperty is
>>just
>> a data structure and doesn't add to the set of APIs for a class
>>definition.
>>
>> I just realized that the class names are used by SimpleCSSValuesImpl to
>> determine the type selectors. So if you rename those strings you will
>> have to change your CSS.
>>
>> Also, I have not removed the exportSymbol calls on each class yet. I
>>will
>> try that as well.
>>
>> -Alex
>>
>>
>> On 8/9/17, 2:11 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>>>
>>>> On Aug 9, 2017, at 11:56 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>> wrote:
>>>>
>>>> The change I just made should only be for MXML. But I think I saw
>>>>that
>>>> I
>>>> never did remove the @export for getters and setters in AS. However,
>>>> doing so would probably break MXML setting of those properties.
>>>>
>>>> I don't think you can tell when compiling a SWC which properties
>>>>someone
>>>> is going to use from MXML, so I'm not sure passing through @export or
>>>> somehow marking certain APIs as "don't rename" is going to be useful.
>>>
>>> It would be useful for client code because I do know which properties
>>>my
>>> MXML will use.
>>>
>>>> On
>>>> the other hand, MXML does know every property that you accessed from
>>>> MXML
>>>> so maybe that's what I'll try next. I think I see an API in GCC where
>>>> you
>>>> can tell it things that shouldn't be renamed.
>>>
>>> That sounds interesting.
>>>
>>>> IMO, this is a bug or missing capability in GCC. They don't see
>>>> Object.defineProperties as part of the class definition so they don't
>>>> track the renames properly. So, removing @exports from getters in AS
>>>> may
>>>> also just fail in calls from other AS classes.
>>>
>>> I lost you. Where did you see that GCC doesn’t track the definitions?
>>>
>>>> Regarding obfuscation, if we have to export getters, is that really
>>>> exposing important secrets?
>>>
>>> Not sure, but I’d like to keep the code as difficult to follow as
>>> possible.
>>>
>>>> The actual code for a getter/setter is
>>>> elsewhere in the output file. It might be possible to do string
>>>> replacement on the exported names after the minification.
>>>
>>> String replacement is definitely an option if it comes to that. I’m
>>> probably going to do that for class names and paths as I don’t really
>>>see
>>> that we currently have a solution for that.
>>>
>>>> Thoughts?
>>>> -Alex
>>>>
>>>> On 8/9/17, 1:24 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>
>>>>> I just compiled with the new option and it appears to work. Yay. On
>>>>>the
>>>>> other hand, only functions and variables are being minified. getters
>>>>> and
>>>>> setters (which is a very large percentage of the signature of my
>>>>>code)
>>>>> is
>>>>> not.
>>>>>
>>>>> It looks like that adds the @exports for non-mxml files as well. Can
>>>>>we
>>>>> output the @exports for only MXML declared variables?
>>>>>
>>>>> If a comment with @export is added in AS code, will that be passed
>>>>> through to the JS output?
>>>>>
>>>>> If yes, I think @exporting ids declared in MXML should be the only
>>>>>case
>>>>> we need. I can probably handle any specific cases where that might
>>>>> break
>>>>> output code by manually inserting @export statements.
>>>>>
>>>>>> On Aug 9, 2017, at 10:20 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>>>> wrote:
>>>>>>
>>>>>> Hmm. I thought GCC didn't rename those. Anyway, I added back the
>>>>>> @export. See if that works for you and then see if you think there
>>>>>>is
>>>>>> enough obfuscation.
>>>>>>
>>>>>> Thanks,
>>>>>> -Alex
>>>>>>
>>>>>> On 8/9/17, 12:45 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>
>>>>>>> The problem is as follows:
>>>>>>>
>>>>>>> Taking textInput as an example, the MXML gets compiled into the
>>>>>>> following:
>>>>>>> textInput: {
>>>>>>> /** @this {com.printui.view.components.PaletteSlider} */
>>>>>>> get: function() {
>>>>>>> return this.textInput_;
>>>>>>> },
>>>>>>> /** @this {com.printui.view.components.PaletteSlider} */
>>>>>>> set: function(value) {
>>>>>>> if (value != this.textInput_) {
>>>>>>> this.textInput_ = value;
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>this.dispatchEvent(org.apache.flex.events.ValueChangeEvent.createUpd
>>>>>>>at
>>>>>>> eE
>>>>>>> ve
>>>>>>> nt(this, 'textInput', null, value));
>>>>>>> }
>>>>>>> }
>>>>>>> },
>>>>>>>
>>>>>>> which gets minified to this:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>yw:{get:r('Nja'),set:function(a){a!=this.Nja&&(this.Nja=a,this.dispa
>>>>>>>tc
>>>>>>> hE
>>>>>>> ve
>>>>>>> nt(yR(this,iI,null,a)))}}
>>>>>>>
>>>>>>> goog has no way of knowing that the original textInput property
>>>>>>>name
>>>>>>> is
>>>>>>> used anywhere so all references to textInput are changed to yw.
>>>>>>>
>>>>>>> I think the solution to this is to add @export tags to the
>>>>>>> Object.defineProperty specification for any property that’s
>>>>>>>declared
>>>>>>> or
>>>>>>> used in the MXML.
>>>>>>>
>>>>>>> If localId is used, there might be another option which would be to
>>>>>>> rename the id to some value that’s one or two characters long. I’m
>>>>>>> pretty
>>>>>>> sure that goog will not rename really short property names like
>>>>>>>that.
>>>>>>> (We
>>>>>>> can’t do that for id because it might be used by CSS.)
>>>>>>>
>>>>>>> Harbs
>>>>>>>
>>>>>>>> On Aug 9, 2017, at 10:25 AM, Harbs <ha...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Here’s a problem I ran into:
>>>>>>>>
>>>>>>>> I have a component which has the following:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa
>>>>>>>>st
>>>>>>>> e.
>>>>>>>> ap
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>ache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99bb%
>>>>>>>>7C
>>>>>>>> fa
>>>>>>>> 7b
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=FPa
>>>>>>>>am
>>>>>>>> WR
>>>>>>>> Ac
>>>>>>>> t5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fp
>>>>>>>>as
>>>>>>>> te
>>>>>>>> .a
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>pache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99bb
>>>>>>>>%7
>>>>>>>> Cf
>>>>>>>> a7
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=FP
>>>>>>>>aa
>>>>>>>> mW
>>>>>>>> RA
>>>>>>>> ct5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0>
>>>>>>>>
>>>>>>>> In the script block I have references to disableBead, textInput,
>>>>>>>> etc.
>>>>>>>>
>>>>>>>> The instance correctly has properties of disableBead, textInput,
>>>>>>>> etc.,
>>>>>>>> but every reference to these properties is renamed.
>>>>>>>>
>>>>>>>> textInput.addEventListener
>>>>>>>> becomes:
>>>>>>>> this.yw.addEventListener
>>>>>>>>
>>>>>>>> disableBead.disabled
>>>>>>>> becomes
>>>>>>>> this.Jm.disabled
>>>>>>>>
>>>>>>>> etc.
>>>>>>>>
>>>>>>>> this.yw and this.Jm are both undefined
>>>>>>>>
>>>>>>>>> On Aug 9, 2017, at 9:10 AM, Harbs <harbs.lists@gmail.com
>>>>>>>>> <ma...@gmail.com>> wrote:
>>>>>>>>>
>>>>>>>>> I’ll give it a go and see.
>>>>>>>>>
>>>>>>>>>> On Aug 9, 2017, at 8:31 AM, Alex Harui <aharui@adobe.com.INVALID
>>>>>>>>>> <ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com
>>>>>>>>>> <ma...@gmail.com>> 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
>>>>>>>>>>>><aharui@adobe.com.INVALID
>>>>>>>>>>>> <ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com
>>>>>>>>>>>> <ma...@gmail.com>> 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
>>>>>>>>>>>>>> <aharui@adobe.com.INVALID
>>>>>>>>>>>>>> <ma...@adobe.com.INVALID>>
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Package, Class and Method renaming
Posted by Harbs <ha...@gmail.com>.
For kicks I tried modifying the compiler to not emit @export for my code (it still has the @exports for SDK code).
The result on code size was more than 50KB smaller AFTER gzipping. That’s a reduction of more than 10%. Pretty significant. That’s without any class renaming.
Anyway, it blew up my app on properties that were used in data binding in MXML. I didn’t fix that to see the next place it blew up.
If we go this route, we probably need to make MXML output smarter…
> On Aug 10, 2017, at 12:31 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> I've seen GCC not track renames before. The Object.defineProperty is just
> a data structure and doesn't add to the set of APIs for a class definition.
>
> I just realized that the class names are used by SimpleCSSValuesImpl to
> determine the type selectors. So if you rename those strings you will
> have to change your CSS.
>
> Also, I have not removed the exportSymbol calls on each class yet. I will
> try that as well.
>
> -Alex
>
>
> On 8/9/17, 2:11 PM, "Harbs" <ha...@gmail.com> wrote:
>
>>
>>> On Aug 9, 2017, at 11:56 PM, Alex Harui <ah...@adobe.com.INVALID>
>>> wrote:
>>>
>>> The change I just made should only be for MXML. But I think I saw that
>>> I
>>> never did remove the @export for getters and setters in AS. However,
>>> doing so would probably break MXML setting of those properties.
>>>
>>> I don't think you can tell when compiling a SWC which properties someone
>>> is going to use from MXML, so I'm not sure passing through @export or
>>> somehow marking certain APIs as "don't rename" is going to be useful.
>>
>> It would be useful for client code because I do know which properties my
>> MXML will use.
>>
>>> On
>>> the other hand, MXML does know every property that you accessed from
>>> MXML
>>> so maybe that's what I'll try next. I think I see an API in GCC where
>>> you
>>> can tell it things that shouldn't be renamed.
>>
>> That sounds interesting.
>>
>>> IMO, this is a bug or missing capability in GCC. They don't see
>>> Object.defineProperties as part of the class definition so they don't
>>> track the renames properly. So, removing @exports from getters in AS
>>> may
>>> also just fail in calls from other AS classes.
>>
>> I lost you. Where did you see that GCC doesn’t track the definitions?
>>
>>> Regarding obfuscation, if we have to export getters, is that really
>>> exposing important secrets?
>>
>> Not sure, but I’d like to keep the code as difficult to follow as
>> possible.
>>
>>> The actual code for a getter/setter is
>>> elsewhere in the output file. It might be possible to do string
>>> replacement on the exported names after the minification.
>>
>> String replacement is definitely an option if it comes to that. I’m
>> probably going to do that for class names and paths as I don’t really see
>> that we currently have a solution for that.
>>
>>> Thoughts?
>>> -Alex
>>>
>>> On 8/9/17, 1:24 PM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>>> I just compiled with the new option and it appears to work. Yay. On the
>>>> other hand, only functions and variables are being minified. getters
>>>> and
>>>> setters (which is a very large percentage of the signature of my code)
>>>> is
>>>> not.
>>>>
>>>> It looks like that adds the @exports for non-mxml files as well. Can we
>>>> output the @exports for only MXML declared variables?
>>>>
>>>> If a comment with @export is added in AS code, will that be passed
>>>> through to the JS output?
>>>>
>>>> If yes, I think @exporting ids declared in MXML should be the only case
>>>> we need. I can probably handle any specific cases where that might
>>>> break
>>>> output code by manually inserting @export statements.
>>>>
>>>>> On Aug 9, 2017, at 10:20 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>>> wrote:
>>>>>
>>>>> Hmm. I thought GCC didn't rename those. Anyway, I added back the
>>>>> @export. See if that works for you and then see if you think there is
>>>>> enough obfuscation.
>>>>>
>>>>> Thanks,
>>>>> -Alex
>>>>>
>>>>> On 8/9/17, 12:45 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>
>>>>>> The problem is as follows:
>>>>>>
>>>>>> Taking textInput as an example, the MXML gets compiled into the
>>>>>> following:
>>>>>> textInput: {
>>>>>> /** @this {com.printui.view.components.PaletteSlider} */
>>>>>> get: function() {
>>>>>> return this.textInput_;
>>>>>> },
>>>>>> /** @this {com.printui.view.components.PaletteSlider} */
>>>>>> set: function(value) {
>>>>>> if (value != this.textInput_) {
>>>>>> this.textInput_ = value;
>>>>>>
>>>>>>
>>>>>>
>>>>>> this.dispatchEvent(org.apache.flex.events.ValueChangeEvent.createUpdat
>>>>>> eE
>>>>>> ve
>>>>>> nt(this, 'textInput', null, value));
>>>>>> }
>>>>>> }
>>>>>> },
>>>>>>
>>>>>> which gets minified to this:
>>>>>>
>>>>>>
>>>>>>
>>>>>> yw:{get:r('Nja'),set:function(a){a!=this.Nja&&(this.Nja=a,this.dispatc
>>>>>> hE
>>>>>> ve
>>>>>> nt(yR(this,iI,null,a)))}}
>>>>>>
>>>>>> goog has no way of knowing that the original textInput property name
>>>>>> is
>>>>>> used anywhere so all references to textInput are changed to yw.
>>>>>>
>>>>>> I think the solution to this is to add @export tags to the
>>>>>> Object.defineProperty specification for any property that’s declared
>>>>>> or
>>>>>> used in the MXML.
>>>>>>
>>>>>> If localId is used, there might be another option which would be to
>>>>>> rename the id to some value that’s one or two characters long. I’m
>>>>>> pretty
>>>>>> sure that goog will not rename really short property names like that.
>>>>>> (We
>>>>>> can’t do that for id because it might be used by CSS.)
>>>>>>
>>>>>> Harbs
>>>>>>
>>>>>>> On Aug 9, 2017, at 10:25 AM, Harbs <ha...@gmail.com> wrote:
>>>>>>>
>>>>>>> Here’s a problem I ran into:
>>>>>>>
>>>>>>> I have a component which has the following:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpast
>>>>>>> e.
>>>>>>> ap
>>>>>>>
>>>>>>>
>>>>>>> ache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99bb%7C
>>>>>>> fa
>>>>>>> 7b
>>>>>>>
>>>>>>>
>>>>>>> 1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=FPaam
>>>>>>> WR
>>>>>>> Ac
>>>>>>> t5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0
>>>>>>>
>>>>>>>
>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpas
>>>>>>> te
>>>>>>> .a
>>>>>>>
>>>>>>>
>>>>>>> pache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99bb%7
>>>>>>> Cf
>>>>>>> a7
>>>>>>>
>>>>>>>
>>>>>>> b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=FPaa
>>>>>>> mW
>>>>>>> RA
>>>>>>> ct5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0>
>>>>>>>
>>>>>>> In the script block I have references to disableBead, textInput,
>>>>>>> etc.
>>>>>>>
>>>>>>> The instance correctly has properties of disableBead, textInput,
>>>>>>> etc.,
>>>>>>> but every reference to these properties is renamed.
>>>>>>>
>>>>>>> textInput.addEventListener
>>>>>>> becomes:
>>>>>>> this.yw.addEventListener
>>>>>>>
>>>>>>> disableBead.disabled
>>>>>>> becomes
>>>>>>> this.Jm.disabled
>>>>>>>
>>>>>>> etc.
>>>>>>>
>>>>>>> this.yw and this.Jm are both undefined
>>>>>>>
>>>>>>>> On Aug 9, 2017, at 9:10 AM, Harbs <harbs.lists@gmail.com
>>>>>>>> <ma...@gmail.com>> wrote:
>>>>>>>>
>>>>>>>> I’ll give it a go and see.
>>>>>>>>
>>>>>>>>> On Aug 9, 2017, at 8:31 AM, Alex Harui <aharui@adobe.com.INVALID
>>>>>>>>> <ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com
>>>>>>>>> <ma...@gmail.com>> 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 <aharui@adobe.com.INVALID
>>>>>>>>>>> <ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com
>>>>>>>>>>> <ma...@gmail.com>> 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
>>>>>>>>>>>>> <aharui@adobe.com.INVALID
>>>>>>>>>>>>> <ma...@adobe.com.INVALID>>
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Package, Class and Method renaming
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I don't think GCC knows how to handle the object literal pattern. It
doesn't seem to know about using the object literal for
Object.defineProperties.
GCC sometimes creates a temp var for foo.prototype. Not quite sure
when/why, but the minified output isn't always repeating foo.prototype for
every API.
Of course, I could be wrong...
-Alex
On 8/9/17, 3:33 PM, "Harbs" <ha...@gmail.com> wrote:
>I hate to visit this topic again, but I’m not sure I understand why we’re
>defining members the way we are.
>
>There’s two ways to define getters and setters.
>
>One is using Object.defineProperties.
>The second is by using object literals.[1]
>
>I believe browser support of the two are the same.
>
>Object literal syntax can only be used when the object is initialized,
>but I don’t see why that’s a problem.
>
>Instead of:
>MyClass.prototype.foo = “baz”;
>MyClass.prototype.baz = function(){
> return “foo”;
>}
>Object.defineProperties(MyClass,
>bar:{
>get: MyClass.__getbar,
>set: MyClass.__setbar})
>
>We could output:
>MyClass.prototype = {
> foo: “baz”,
> baz: function(){
> return “foo”;
> },
> bar:{
> get: MyClass.__getbar,
> set: MyClass.__setbar
> }
>}
>
>Is there a reason I’m not remembering why that’s not an option?
>
>Besides likely helping with the minifying issue, it would likely output
>smaller code. My minified app has 14093 instances of the word prototype.
>
>[1]https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkangax.
>github.io%2Fcompat-table%2Fes5%2F%23test-Object%2Farray_literal_extensions
>_Getter_accessors&data=02%7C01%7C%7C4c8241c7dc364ada739908d4df76c298%7Cfa7
>b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636379148544302372&sdata=zpqBPd3a%
>2B56GwuW6DCMl%2FLHuLrdmgK48ZllY%2F0aibY8%3D&reserved=0
><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkangax.gi
>thub.io%2Fcompat-table%2Fes5%2F%23test-Object%2Farray_literal_extensions_G
>etter_accessors&data=02%7C01%7C%7C4c8241c7dc364ada739908d4df76c298%7Cfa7b1
>b5a7b34438794aed2c178decee1%7C0%7C0%7C636379148544302372&sdata=zpqBPd3a%2B
>56GwuW6DCMl%2FLHuLrdmgK48ZllY%2F0aibY8%3D&reserved=0>
>
>
>> On Aug 10, 2017, at 12:31 AM, Alex Harui <ah...@adobe.com.INVALID>
>>wrote:
>>
>> I've seen GCC not track renames before. The Object.defineProperty is
>>just
>> a data structure and doesn't add to the set of APIs for a class
>>definition.
>>
>> I just realized that the class names are used by SimpleCSSValuesImpl to
>> determine the type selectors. So if you rename those strings you will
>> have to change your CSS.
>>
>> Also, I have not removed the exportSymbol calls on each class yet. I
>>will
>> try that as well.
>>
>> -Alex
>>
>>
>> On 8/9/17, 2:11 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>>>
>>>> On Aug 9, 2017, at 11:56 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>> wrote:
>>>>
>>>> The change I just made should only be for MXML. But I think I saw
>>>>that
>>>> I
>>>> never did remove the @export for getters and setters in AS. However,
>>>> doing so would probably break MXML setting of those properties.
>>>>
>>>> I don't think you can tell when compiling a SWC which properties
>>>>someone
>>>> is going to use from MXML, so I'm not sure passing through @export or
>>>> somehow marking certain APIs as "don't rename" is going to be useful.
>>>
>>> It would be useful for client code because I do know which properties
>>>my
>>> MXML will use.
>>>
>>>> On
>>>> the other hand, MXML does know every property that you accessed from
>>>> MXML
>>>> so maybe that's what I'll try next. I think I see an API in GCC where
>>>> you
>>>> can tell it things that shouldn't be renamed.
>>>
>>> That sounds interesting.
>>>
>>>> IMO, this is a bug or missing capability in GCC. They don't see
>>>> Object.defineProperties as part of the class definition so they don't
>>>> track the renames properly. So, removing @exports from getters in AS
>>>> may
>>>> also just fail in calls from other AS classes.
>>>
>>> I lost you. Where did you see that GCC doesn’t track the definitions?
>>>
>>>> Regarding obfuscation, if we have to export getters, is that really
>>>> exposing important secrets?
>>>
>>> Not sure, but I’d like to keep the code as difficult to follow as
>>> possible.
>>>
>>>> The actual code for a getter/setter is
>>>> elsewhere in the output file. It might be possible to do string
>>>> replacement on the exported names after the minification.
>>>
>>> String replacement is definitely an option if it comes to that. I’m
>>> probably going to do that for class names and paths as I don’t really
>>>see
>>> that we currently have a solution for that.
>>>
>>>> Thoughts?
>>>> -Alex
>>>>
>>>> On 8/9/17, 1:24 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>
>>>>> I just compiled with the new option and it appears to work. Yay. On
>>>>>the
>>>>> other hand, only functions and variables are being minified. getters
>>>>> and
>>>>> setters (which is a very large percentage of the signature of my
>>>>>code)
>>>>> is
>>>>> not.
>>>>>
>>>>> It looks like that adds the @exports for non-mxml files as well. Can
>>>>>we
>>>>> output the @exports for only MXML declared variables?
>>>>>
>>>>> If a comment with @export is added in AS code, will that be passed
>>>>> through to the JS output?
>>>>>
>>>>> If yes, I think @exporting ids declared in MXML should be the only
>>>>>case
>>>>> we need. I can probably handle any specific cases where that might
>>>>> break
>>>>> output code by manually inserting @export statements.
>>>>>
>>>>>> On Aug 9, 2017, at 10:20 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>>>> wrote:
>>>>>>
>>>>>> Hmm. I thought GCC didn't rename those. Anyway, I added back the
>>>>>> @export. See if that works for you and then see if you think there
>>>>>>is
>>>>>> enough obfuscation.
>>>>>>
>>>>>> Thanks,
>>>>>> -Alex
>>>>>>
>>>>>> On 8/9/17, 12:45 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>
>>>>>>> The problem is as follows:
>>>>>>>
>>>>>>> Taking textInput as an example, the MXML gets compiled into the
>>>>>>> following:
>>>>>>> textInput: {
>>>>>>> /** @this {com.printui.view.components.PaletteSlider} */
>>>>>>> get: function() {
>>>>>>> return this.textInput_;
>>>>>>> },
>>>>>>> /** @this {com.printui.view.components.PaletteSlider} */
>>>>>>> set: function(value) {
>>>>>>> if (value != this.textInput_) {
>>>>>>> this.textInput_ = value;
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>this.dispatchEvent(org.apache.flex.events.ValueChangeEvent.createUpd
>>>>>>>at
>>>>>>> eE
>>>>>>> ve
>>>>>>> nt(this, 'textInput', null, value));
>>>>>>> }
>>>>>>> }
>>>>>>> },
>>>>>>>
>>>>>>> which gets minified to this:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>yw:{get:r('Nja'),set:function(a){a!=this.Nja&&(this.Nja=a,this.dispa
>>>>>>>tc
>>>>>>> hE
>>>>>>> ve
>>>>>>> nt(yR(this,iI,null,a)))}}
>>>>>>>
>>>>>>> goog has no way of knowing that the original textInput property
>>>>>>>name
>>>>>>> is
>>>>>>> used anywhere so all references to textInput are changed to yw.
>>>>>>>
>>>>>>> I think the solution to this is to add @export tags to the
>>>>>>> Object.defineProperty specification for any property that’s
>>>>>>>declared
>>>>>>> or
>>>>>>> used in the MXML.
>>>>>>>
>>>>>>> If localId is used, there might be another option which would be to
>>>>>>> rename the id to some value that’s one or two characters long. I’m
>>>>>>> pretty
>>>>>>> sure that goog will not rename really short property names like
>>>>>>>that.
>>>>>>> (We
>>>>>>> can’t do that for id because it might be used by CSS.)
>>>>>>>
>>>>>>> Harbs
>>>>>>>
>>>>>>>> On Aug 9, 2017, at 10:25 AM, Harbs <ha...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Here’s a problem I ran into:
>>>>>>>>
>>>>>>>> I have a component which has the following:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa
>>>>>>>>st
>>>>>>>> e.
>>>>>>>> ap
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>ache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99bb%
>>>>>>>>7C
>>>>>>>> fa
>>>>>>>> 7b
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=FPa
>>>>>>>>am
>>>>>>>> WR
>>>>>>>> Ac
>>>>>>>> t5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fp
>>>>>>>>as
>>>>>>>> te
>>>>>>>> .a
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>pache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99bb
>>>>>>>>%7
>>>>>>>> Cf
>>>>>>>> a7
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=FP
>>>>>>>>aa
>>>>>>>> mW
>>>>>>>> RA
>>>>>>>> ct5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0>
>>>>>>>>
>>>>>>>> In the script block I have references to disableBead, textInput,
>>>>>>>> etc.
>>>>>>>>
>>>>>>>> The instance correctly has properties of disableBead, textInput,
>>>>>>>> etc.,
>>>>>>>> but every reference to these properties is renamed.
>>>>>>>>
>>>>>>>> textInput.addEventListener
>>>>>>>> becomes:
>>>>>>>> this.yw.addEventListener
>>>>>>>>
>>>>>>>> disableBead.disabled
>>>>>>>> becomes
>>>>>>>> this.Jm.disabled
>>>>>>>>
>>>>>>>> etc.
>>>>>>>>
>>>>>>>> this.yw and this.Jm are both undefined
>>>>>>>>
>>>>>>>>> On Aug 9, 2017, at 9:10 AM, Harbs <harbs.lists@gmail.com
>>>>>>>>> <ma...@gmail.com>> wrote:
>>>>>>>>>
>>>>>>>>> I’ll give it a go and see.
>>>>>>>>>
>>>>>>>>>> On Aug 9, 2017, at 8:31 AM, Alex Harui <aharui@adobe.com.INVALID
>>>>>>>>>> <ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com
>>>>>>>>>> <ma...@gmail.com>> 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
>>>>>>>>>>>><aharui@adobe.com.INVALID
>>>>>>>>>>>> <ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com
>>>>>>>>>>>> <ma...@gmail.com>> 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
>>>>>>>>>>>>>> <aharui@adobe.com.INVALID
>>>>>>>>>>>>>> <ma...@adobe.com.INVALID>>
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Package, Class and Method renaming
Posted by Harbs <ha...@gmail.com>.
I hate to visit this topic again, but I’m not sure I understand why we’re defining members the way we are.
There’s two ways to define getters and setters.
One is using Object.defineProperties.
The second is by using object literals.[1]
I believe browser support of the two are the same.
Object literal syntax can only be used when the object is initialized, but I don’t see why that’s a problem.
Instead of:
MyClass.prototype.foo = “baz”;
MyClass.prototype.baz = function(){
return “foo”;
}
Object.defineProperties(MyClass,
bar:{
get: MyClass.__getbar,
set: MyClass.__setbar})
We could output:
MyClass.prototype = {
foo: “baz”,
baz: function(){
return “foo”;
},
bar:{
get: MyClass.__getbar,
set: MyClass.__setbar
}
}
Is there a reason I’m not remembering why that’s not an option?
Besides likely helping with the minifying issue, it would likely output smaller code. My minified app has 14093 instances of the word prototype.
[1]http://kangax.github.io/compat-table/es5/#test-Object/array_literal_extensions_Getter_accessors <http://kangax.github.io/compat-table/es5/#test-Object/array_literal_extensions_Getter_accessors>
> On Aug 10, 2017, at 12:31 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> I've seen GCC not track renames before. The Object.defineProperty is just
> a data structure and doesn't add to the set of APIs for a class definition.
>
> I just realized that the class names are used by SimpleCSSValuesImpl to
> determine the type selectors. So if you rename those strings you will
> have to change your CSS.
>
> Also, I have not removed the exportSymbol calls on each class yet. I will
> try that as well.
>
> -Alex
>
>
> On 8/9/17, 2:11 PM, "Harbs" <ha...@gmail.com> wrote:
>
>>
>>> On Aug 9, 2017, at 11:56 PM, Alex Harui <ah...@adobe.com.INVALID>
>>> wrote:
>>>
>>> The change I just made should only be for MXML. But I think I saw that
>>> I
>>> never did remove the @export for getters and setters in AS. However,
>>> doing so would probably break MXML setting of those properties.
>>>
>>> I don't think you can tell when compiling a SWC which properties someone
>>> is going to use from MXML, so I'm not sure passing through @export or
>>> somehow marking certain APIs as "don't rename" is going to be useful.
>>
>> It would be useful for client code because I do know which properties my
>> MXML will use.
>>
>>> On
>>> the other hand, MXML does know every property that you accessed from
>>> MXML
>>> so maybe that's what I'll try next. I think I see an API in GCC where
>>> you
>>> can tell it things that shouldn't be renamed.
>>
>> That sounds interesting.
>>
>>> IMO, this is a bug or missing capability in GCC. They don't see
>>> Object.defineProperties as part of the class definition so they don't
>>> track the renames properly. So, removing @exports from getters in AS
>>> may
>>> also just fail in calls from other AS classes.
>>
>> I lost you. Where did you see that GCC doesn’t track the definitions?
>>
>>> Regarding obfuscation, if we have to export getters, is that really
>>> exposing important secrets?
>>
>> Not sure, but I’d like to keep the code as difficult to follow as
>> possible.
>>
>>> The actual code for a getter/setter is
>>> elsewhere in the output file. It might be possible to do string
>>> replacement on the exported names after the minification.
>>
>> String replacement is definitely an option if it comes to that. I’m
>> probably going to do that for class names and paths as I don’t really see
>> that we currently have a solution for that.
>>
>>> Thoughts?
>>> -Alex
>>>
>>> On 8/9/17, 1:24 PM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>>> I just compiled with the new option and it appears to work. Yay. On the
>>>> other hand, only functions and variables are being minified. getters
>>>> and
>>>> setters (which is a very large percentage of the signature of my code)
>>>> is
>>>> not.
>>>>
>>>> It looks like that adds the @exports for non-mxml files as well. Can we
>>>> output the @exports for only MXML declared variables?
>>>>
>>>> If a comment with @export is added in AS code, will that be passed
>>>> through to the JS output?
>>>>
>>>> If yes, I think @exporting ids declared in MXML should be the only case
>>>> we need. I can probably handle any specific cases where that might
>>>> break
>>>> output code by manually inserting @export statements.
>>>>
>>>>> On Aug 9, 2017, at 10:20 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>>> wrote:
>>>>>
>>>>> Hmm. I thought GCC didn't rename those. Anyway, I added back the
>>>>> @export. See if that works for you and then see if you think there is
>>>>> enough obfuscation.
>>>>>
>>>>> Thanks,
>>>>> -Alex
>>>>>
>>>>> On 8/9/17, 12:45 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>
>>>>>> The problem is as follows:
>>>>>>
>>>>>> Taking textInput as an example, the MXML gets compiled into the
>>>>>> following:
>>>>>> textInput: {
>>>>>> /** @this {com.printui.view.components.PaletteSlider} */
>>>>>> get: function() {
>>>>>> return this.textInput_;
>>>>>> },
>>>>>> /** @this {com.printui.view.components.PaletteSlider} */
>>>>>> set: function(value) {
>>>>>> if (value != this.textInput_) {
>>>>>> this.textInput_ = value;
>>>>>>
>>>>>>
>>>>>>
>>>>>> this.dispatchEvent(org.apache.flex.events.ValueChangeEvent.createUpdat
>>>>>> eE
>>>>>> ve
>>>>>> nt(this, 'textInput', null, value));
>>>>>> }
>>>>>> }
>>>>>> },
>>>>>>
>>>>>> which gets minified to this:
>>>>>>
>>>>>>
>>>>>>
>>>>>> yw:{get:r('Nja'),set:function(a){a!=this.Nja&&(this.Nja=a,this.dispatc
>>>>>> hE
>>>>>> ve
>>>>>> nt(yR(this,iI,null,a)))}}
>>>>>>
>>>>>> goog has no way of knowing that the original textInput property name
>>>>>> is
>>>>>> used anywhere so all references to textInput are changed to yw.
>>>>>>
>>>>>> I think the solution to this is to add @export tags to the
>>>>>> Object.defineProperty specification for any property that’s declared
>>>>>> or
>>>>>> used in the MXML.
>>>>>>
>>>>>> If localId is used, there might be another option which would be to
>>>>>> rename the id to some value that’s one or two characters long. I’m
>>>>>> pretty
>>>>>> sure that goog will not rename really short property names like that.
>>>>>> (We
>>>>>> can’t do that for id because it might be used by CSS.)
>>>>>>
>>>>>> Harbs
>>>>>>
>>>>>>> On Aug 9, 2017, at 10:25 AM, Harbs <ha...@gmail.com> wrote:
>>>>>>>
>>>>>>> Here’s a problem I ran into:
>>>>>>>
>>>>>>> I have a component which has the following:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpast
>>>>>>> e.
>>>>>>> ap
>>>>>>>
>>>>>>>
>>>>>>> ache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99bb%7C
>>>>>>> fa
>>>>>>> 7b
>>>>>>>
>>>>>>>
>>>>>>> 1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=FPaam
>>>>>>> WR
>>>>>>> Ac
>>>>>>> t5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0
>>>>>>>
>>>>>>>
>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpas
>>>>>>> te
>>>>>>> .a
>>>>>>>
>>>>>>>
>>>>>>> pache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99bb%7
>>>>>>> Cf
>>>>>>> a7
>>>>>>>
>>>>>>>
>>>>>>> b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=FPaa
>>>>>>> mW
>>>>>>> RA
>>>>>>> ct5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0>
>>>>>>>
>>>>>>> In the script block I have references to disableBead, textInput,
>>>>>>> etc.
>>>>>>>
>>>>>>> The instance correctly has properties of disableBead, textInput,
>>>>>>> etc.,
>>>>>>> but every reference to these properties is renamed.
>>>>>>>
>>>>>>> textInput.addEventListener
>>>>>>> becomes:
>>>>>>> this.yw.addEventListener
>>>>>>>
>>>>>>> disableBead.disabled
>>>>>>> becomes
>>>>>>> this.Jm.disabled
>>>>>>>
>>>>>>> etc.
>>>>>>>
>>>>>>> this.yw and this.Jm are both undefined
>>>>>>>
>>>>>>>> On Aug 9, 2017, at 9:10 AM, Harbs <harbs.lists@gmail.com
>>>>>>>> <ma...@gmail.com>> wrote:
>>>>>>>>
>>>>>>>> I’ll give it a go and see.
>>>>>>>>
>>>>>>>>> On Aug 9, 2017, at 8:31 AM, Alex Harui <aharui@adobe.com.INVALID
>>>>>>>>> <ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com
>>>>>>>>> <ma...@gmail.com>> 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 <aharui@adobe.com.INVALID
>>>>>>>>>>> <ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com
>>>>>>>>>>> <ma...@gmail.com>> 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
>>>>>>>>>>>>> <aharui@adobe.com.INVALID
>>>>>>>>>>>>> <ma...@adobe.com.INVALID>>
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Package, Class and Method renaming
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I've seen GCC not track renames before. The Object.defineProperty is just
a data structure and doesn't add to the set of APIs for a class definition.
I just realized that the class names are used by SimpleCSSValuesImpl to
determine the type selectors. So if you rename those strings you will
have to change your CSS.
Also, I have not removed the exportSymbol calls on each class yet. I will
try that as well.
-Alex
On 8/9/17, 2:11 PM, "Harbs" <ha...@gmail.com> wrote:
>
>> On Aug 9, 2017, at 11:56 PM, Alex Harui <ah...@adobe.com.INVALID>
>>wrote:
>>
>> The change I just made should only be for MXML. But I think I saw that
>>I
>> never did remove the @export for getters and setters in AS. However,
>> doing so would probably break MXML setting of those properties.
>>
>> I don't think you can tell when compiling a SWC which properties someone
>> is going to use from MXML, so I'm not sure passing through @export or
>> somehow marking certain APIs as "don't rename" is going to be useful.
>
>It would be useful for client code because I do know which properties my
>MXML will use.
>
>> On
>> the other hand, MXML does know every property that you accessed from
>>MXML
>> so maybe that's what I'll try next. I think I see an API in GCC where
>>you
>> can tell it things that shouldn't be renamed.
>
>That sounds interesting.
>
>> IMO, this is a bug or missing capability in GCC. They don't see
>> Object.defineProperties as part of the class definition so they don't
>> track the renames properly. So, removing @exports from getters in AS
>>may
>> also just fail in calls from other AS classes.
>
>I lost you. Where did you see that GCC doesn’t track the definitions?
>
>> Regarding obfuscation, if we have to export getters, is that really
>> exposing important secrets?
>
>Not sure, but I’d like to keep the code as difficult to follow as
>possible.
>
>> The actual code for a getter/setter is
>> elsewhere in the output file. It might be possible to do string
>> replacement on the exported names after the minification.
>
>String replacement is definitely an option if it comes to that. I’m
>probably going to do that for class names and paths as I don’t really see
>that we currently have a solution for that.
>
>> Thoughts?
>> -Alex
>>
>> On 8/9/17, 1:24 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>>> I just compiled with the new option and it appears to work. Yay. On the
>>> other hand, only functions and variables are being minified. getters
>>>and
>>> setters (which is a very large percentage of the signature of my code)
>>>is
>>> not.
>>>
>>> It looks like that adds the @exports for non-mxml files as well. Can we
>>> output the @exports for only MXML declared variables?
>>>
>>> If a comment with @export is added in AS code, will that be passed
>>> through to the JS output?
>>>
>>> If yes, I think @exporting ids declared in MXML should be the only case
>>> we need. I can probably handle any specific cases where that might
>>>break
>>> output code by manually inserting @export statements.
>>>
>>>> On Aug 9, 2017, at 10:20 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>> wrote:
>>>>
>>>> Hmm. I thought GCC didn't rename those. Anyway, I added back the
>>>> @export. See if that works for you and then see if you think there is
>>>> enough obfuscation.
>>>>
>>>> Thanks,
>>>> -Alex
>>>>
>>>> On 8/9/17, 12:45 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>
>>>>> The problem is as follows:
>>>>>
>>>>> Taking textInput as an example, the MXML gets compiled into the
>>>>> following:
>>>>> textInput: {
>>>>> /** @this {com.printui.view.components.PaletteSlider} */
>>>>> get: function() {
>>>>> return this.textInput_;
>>>>> },
>>>>> /** @this {com.printui.view.components.PaletteSlider} */
>>>>> set: function(value) {
>>>>> if (value != this.textInput_) {
>>>>> this.textInput_ = value;
>>>>>
>>>>>
>>>>>
>>>>>this.dispatchEvent(org.apache.flex.events.ValueChangeEvent.createUpdat
>>>>>eE
>>>>> ve
>>>>> nt(this, 'textInput', null, value));
>>>>> }
>>>>> }
>>>>> },
>>>>>
>>>>> which gets minified to this:
>>>>>
>>>>>
>>>>>
>>>>>yw:{get:r('Nja'),set:function(a){a!=this.Nja&&(this.Nja=a,this.dispatc
>>>>>hE
>>>>> ve
>>>>> nt(yR(this,iI,null,a)))}}
>>>>>
>>>>> goog has no way of knowing that the original textInput property name
>>>>>is
>>>>> used anywhere so all references to textInput are changed to yw.
>>>>>
>>>>> I think the solution to this is to add @export tags to the
>>>>> Object.defineProperty specification for any property that’s declared
>>>>>or
>>>>> used in the MXML.
>>>>>
>>>>> If localId is used, there might be another option which would be to
>>>>> rename the id to some value that’s one or two characters long. I’m
>>>>> pretty
>>>>> sure that goog will not rename really short property names like that.
>>>>> (We
>>>>> can’t do that for id because it might be used by CSS.)
>>>>>
>>>>> Harbs
>>>>>
>>>>>> On Aug 9, 2017, at 10:25 AM, Harbs <ha...@gmail.com> wrote:
>>>>>>
>>>>>> Here’s a problem I ran into:
>>>>>>
>>>>>> I have a component which has the following:
>>>>>>
>>>>>>
>>>>>>
>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpast
>>>>>>e.
>>>>>> ap
>>>>>>
>>>>>>
>>>>>>ache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99bb%7C
>>>>>>fa
>>>>>> 7b
>>>>>>
>>>>>>
>>>>>>1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=FPaam
>>>>>>WR
>>>>>> Ac
>>>>>> t5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0
>>>>>>
>>>>>>
>>>>>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpas
>>>>>>te
>>>>>> .a
>>>>>>
>>>>>>
>>>>>>pache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99bb%7
>>>>>>Cf
>>>>>> a7
>>>>>>
>>>>>>
>>>>>>b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=FPaa
>>>>>>mW
>>>>>> RA
>>>>>> ct5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0>
>>>>>>
>>>>>> In the script block I have references to disableBead, textInput,
>>>>>>etc.
>>>>>>
>>>>>> The instance correctly has properties of disableBead, textInput,
>>>>>>etc.,
>>>>>> but every reference to these properties is renamed.
>>>>>>
>>>>>> textInput.addEventListener
>>>>>> becomes:
>>>>>> this.yw.addEventListener
>>>>>>
>>>>>> disableBead.disabled
>>>>>> becomes
>>>>>> this.Jm.disabled
>>>>>>
>>>>>> etc.
>>>>>>
>>>>>> this.yw and this.Jm are both undefined
>>>>>>
>>>>>>> On Aug 9, 2017, at 9:10 AM, Harbs <harbs.lists@gmail.com
>>>>>>> <ma...@gmail.com>> wrote:
>>>>>>>
>>>>>>> I’ll give it a go and see.
>>>>>>>
>>>>>>>> On Aug 9, 2017, at 8:31 AM, Alex Harui <aharui@adobe.com.INVALID
>>>>>>>> <ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com
>>>>>>>> <ma...@gmail.com>> 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 <aharui@adobe.com.INVALID
>>>>>>>>>> <ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com
>>>>>>>>>> <ma...@gmail.com>> 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
>>>>>>>>>>>> <aharui@adobe.com.INVALID
>>>>>>>>>>>> <ma...@adobe.com.INVALID>>
>>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Package, Class and Method renaming
Posted by Harbs <ha...@gmail.com>.
> On Aug 9, 2017, at 11:56 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> The change I just made should only be for MXML. But I think I saw that I
> never did remove the @export for getters and setters in AS. However,
> doing so would probably break MXML setting of those properties.
>
> I don't think you can tell when compiling a SWC which properties someone
> is going to use from MXML, so I'm not sure passing through @export or
> somehow marking certain APIs as "don't rename" is going to be useful.
It would be useful for client code because I do know which properties my MXML will use.
> On
> the other hand, MXML does know every property that you accessed from MXML
> so maybe that's what I'll try next. I think I see an API in GCC where you
> can tell it things that shouldn't be renamed.
That sounds interesting.
> IMO, this is a bug or missing capability in GCC. They don't see
> Object.defineProperties as part of the class definition so they don't
> track the renames properly. So, removing @exports from getters in AS may
> also just fail in calls from other AS classes.
I lost you. Where did you see that GCC doesn’t track the definitions?
> Regarding obfuscation, if we have to export getters, is that really
> exposing important secrets?
Not sure, but I’d like to keep the code as difficult to follow as possible.
> The actual code for a getter/setter is
> elsewhere in the output file. It might be possible to do string
> replacement on the exported names after the minification.
String replacement is definitely an option if it comes to that. I’m probably going to do that for class names and paths as I don’t really see that we currently have a solution for that.
> Thoughts?
> -Alex
>
> On 8/9/17, 1:24 PM, "Harbs" <ha...@gmail.com> wrote:
>
>> I just compiled with the new option and it appears to work. Yay. On the
>> other hand, only functions and variables are being minified. getters and
>> setters (which is a very large percentage of the signature of my code) is
>> not.
>>
>> It looks like that adds the @exports for non-mxml files as well. Can we
>> output the @exports for only MXML declared variables?
>>
>> If a comment with @export is added in AS code, will that be passed
>> through to the JS output?
>>
>> If yes, I think @exporting ids declared in MXML should be the only case
>> we need. I can probably handle any specific cases where that might break
>> output code by manually inserting @export statements.
>>
>>> On Aug 9, 2017, at 10:20 PM, Alex Harui <ah...@adobe.com.INVALID>
>>> wrote:
>>>
>>> Hmm. I thought GCC didn't rename those. Anyway, I added back the
>>> @export. See if that works for you and then see if you think there is
>>> enough obfuscation.
>>>
>>> Thanks,
>>> -Alex
>>>
>>> On 8/9/17, 12:45 AM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>>> The problem is as follows:
>>>>
>>>> Taking textInput as an example, the MXML gets compiled into the
>>>> following:
>>>> textInput: {
>>>> /** @this {com.printui.view.components.PaletteSlider} */
>>>> get: function() {
>>>> return this.textInput_;
>>>> },
>>>> /** @this {com.printui.view.components.PaletteSlider} */
>>>> set: function(value) {
>>>> if (value != this.textInput_) {
>>>> this.textInput_ = value;
>>>>
>>>>
>>>> this.dispatchEvent(org.apache.flex.events.ValueChangeEvent.createUpdateE
>>>> ve
>>>> nt(this, 'textInput', null, value));
>>>> }
>>>> }
>>>> },
>>>>
>>>> which gets minified to this:
>>>>
>>>>
>>>> yw:{get:r('Nja'),set:function(a){a!=this.Nja&&(this.Nja=a,this.dispatchE
>>>> ve
>>>> nt(yR(this,iI,null,a)))}}
>>>>
>>>> goog has no way of knowing that the original textInput property name is
>>>> used anywhere so all references to textInput are changed to yw.
>>>>
>>>> I think the solution to this is to add @export tags to the
>>>> Object.defineProperty specification for any property that’s declared or
>>>> used in the MXML.
>>>>
>>>> If localId is used, there might be another option which would be to
>>>> rename the id to some value that’s one or two characters long. I’m
>>>> pretty
>>>> sure that goog will not rename really short property names like that.
>>>> (We
>>>> can’t do that for id because it might be used by CSS.)
>>>>
>>>> Harbs
>>>>
>>>>> On Aug 9, 2017, at 10:25 AM, Harbs <ha...@gmail.com> wrote:
>>>>>
>>>>> Here’s a problem I ran into:
>>>>>
>>>>> I have a component which has the following:
>>>>>
>>>>>
>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.
>>>>> ap
>>>>>
>>>>> ache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99bb%7Cfa
>>>>> 7b
>>>>>
>>>>> 1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=FPaamWR
>>>>> Ac
>>>>> t5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0
>>>>>
>>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste
>>>>> .a
>>>>>
>>>>> pache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99bb%7Cf
>>>>> a7
>>>>>
>>>>> b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=FPaamW
>>>>> RA
>>>>> ct5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0>
>>>>>
>>>>> In the script block I have references to disableBead, textInput, etc.
>>>>>
>>>>> The instance correctly has properties of disableBead, textInput, etc.,
>>>>> but every reference to these properties is renamed.
>>>>>
>>>>> textInput.addEventListener
>>>>> becomes:
>>>>> this.yw.addEventListener
>>>>>
>>>>> disableBead.disabled
>>>>> becomes
>>>>> this.Jm.disabled
>>>>>
>>>>> etc.
>>>>>
>>>>> this.yw and this.Jm are both undefined
>>>>>
>>>>>> On Aug 9, 2017, at 9:10 AM, Harbs <harbs.lists@gmail.com
>>>>>> <ma...@gmail.com>> wrote:
>>>>>>
>>>>>> I’ll give it a go and see.
>>>>>>
>>>>>>> On Aug 9, 2017, at 8:31 AM, Alex Harui <aharui@adobe.com.INVALID
>>>>>>> <ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com
>>>>>>> <ma...@gmail.com>> 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 <aharui@adobe.com.INVALID
>>>>>>>>> <ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com
>>>>>>>>> <ma...@gmail.com>> 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
>>>>>>>>>>> <aharui@adobe.com.INVALID
>>>>>>>>>>> <ma...@adobe.com.INVALID>>
>>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Package, Class and Method renaming
Posted by Alex Harui <ah...@adobe.com.INVALID>.
The change I just made should only be for MXML. But I think I saw that I
never did remove the @export for getters and setters in AS. However,
doing so would probably break MXML setting of those properties.
I don't think you can tell when compiling a SWC which properties someone
is going to use from MXML, so I'm not sure passing through @export or
somehow marking certain APIs as "don't rename" is going to be useful. On
the other hand, MXML does know every property that you accessed from MXML
so maybe that's what I'll try next. I think I see an API in GCC where you
can tell it things that shouldn't be renamed.
IMO, this is a bug or missing capability in GCC. They don't see
Object.defineProperties as part of the class definition so they don't
track the renames properly. So, removing @exports from getters in AS may
also just fail in calls from other AS classes.
Regarding obfuscation, if we have to export getters, is that really
exposing important secrets? The actual code for a getter/setter is
elsewhere in the output file. It might be possible to do string
replacement on the exported names after the minification.
Thoughts?
-Alex
On 8/9/17, 1:24 PM, "Harbs" <ha...@gmail.com> wrote:
>I just compiled with the new option and it appears to work. Yay. On the
>other hand, only functions and variables are being minified. getters and
>setters (which is a very large percentage of the signature of my code) is
>not.
>
>It looks like that adds the @exports for non-mxml files as well. Can we
>output the @exports for only MXML declared variables?
>
>If a comment with @export is added in AS code, will that be passed
>through to the JS output?
>
>If yes, I think @exporting ids declared in MXML should be the only case
>we need. I can probably handle any specific cases where that might break
>output code by manually inserting @export statements.
>
>> On Aug 9, 2017, at 10:20 PM, Alex Harui <ah...@adobe.com.INVALID>
>>wrote:
>>
>> Hmm. I thought GCC didn't rename those. Anyway, I added back the
>> @export. See if that works for you and then see if you think there is
>> enough obfuscation.
>>
>> Thanks,
>> -Alex
>>
>> On 8/9/17, 12:45 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>>> The problem is as follows:
>>>
>>> Taking textInput as an example, the MXML gets compiled into the
>>>following:
>>> textInput: {
>>> /** @this {com.printui.view.components.PaletteSlider} */
>>> get: function() {
>>> return this.textInput_;
>>> },
>>> /** @this {com.printui.view.components.PaletteSlider} */
>>> set: function(value) {
>>> if (value != this.textInput_) {
>>> this.textInput_ = value;
>>>
>>>
>>>this.dispatchEvent(org.apache.flex.events.ValueChangeEvent.createUpdateE
>>>ve
>>> nt(this, 'textInput', null, value));
>>> }
>>> }
>>> },
>>>
>>> which gets minified to this:
>>>
>>>
>>>yw:{get:r('Nja'),set:function(a){a!=this.Nja&&(this.Nja=a,this.dispatchE
>>>ve
>>> nt(yR(this,iI,null,a)))}}
>>>
>>> goog has no way of knowing that the original textInput property name is
>>> used anywhere so all references to textInput are changed to yw.
>>>
>>> I think the solution to this is to add @export tags to the
>>> Object.defineProperty specification for any property that’s declared or
>>> used in the MXML.
>>>
>>> If localId is used, there might be another option which would be to
>>> rename the id to some value that’s one or two characters long. I’m
>>>pretty
>>> sure that goog will not rename really short property names like that.
>>>(We
>>> can’t do that for id because it might be used by CSS.)
>>>
>>> Harbs
>>>
>>>> On Aug 9, 2017, at 10:25 AM, Harbs <ha...@gmail.com> wrote:
>>>>
>>>> Here’s a problem I ran into:
>>>>
>>>> I have a component which has the following:
>>>>
>>>>
>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.
>>>>ap
>>>>
>>>>ache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99bb%7Cfa
>>>>7b
>>>>
>>>>1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=FPaamWR
>>>>Ac
>>>> t5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0
>>>>
>>>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste
>>>>.a
>>>>
>>>>pache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99bb%7Cf
>>>>a7
>>>>
>>>>b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=FPaamW
>>>>RA
>>>> ct5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0>
>>>>
>>>> In the script block I have references to disableBead, textInput, etc.
>>>>
>>>> The instance correctly has properties of disableBead, textInput, etc.,
>>>> but every reference to these properties is renamed.
>>>>
>>>> textInput.addEventListener
>>>> becomes:
>>>> this.yw.addEventListener
>>>>
>>>> disableBead.disabled
>>>> becomes
>>>> this.Jm.disabled
>>>>
>>>> etc.
>>>>
>>>> this.yw and this.Jm are both undefined
>>>>
>>>>> On Aug 9, 2017, at 9:10 AM, Harbs <harbs.lists@gmail.com
>>>>> <ma...@gmail.com>> wrote:
>>>>>
>>>>> I’ll give it a go and see.
>>>>>
>>>>>> On Aug 9, 2017, at 8:31 AM, Alex Harui <aharui@adobe.com.INVALID
>>>>>> <ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com
>>>>>> <ma...@gmail.com>> 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 <aharui@adobe.com.INVALID
>>>>>>>> <ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com
>>>>>>>> <ma...@gmail.com>> 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
>>>>>>>>>><aharui@adobe.com.INVALID
>>>>>>>>>> <ma...@adobe.com.INVALID>>
>>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Package, Class and Method renaming
Posted by Harbs <ha...@gmail.com>.
I just compiled with the new option and it appears to work. Yay. On the other hand, only functions and variables are being minified. getters and setters (which is a very large percentage of the signature of my code) is not.
It looks like that adds the @exports for non-mxml files as well. Can we output the @exports for only MXML declared variables?
If a comment with @export is added in AS code, will that be passed through to the JS output?
If yes, I think @exporting ids declared in MXML should be the only case we need. I can probably handle any specific cases where that might break output code by manually inserting @export statements.
> On Aug 9, 2017, at 10:20 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Hmm. I thought GCC didn't rename those. Anyway, I added back the
> @export. See if that works for you and then see if you think there is
> enough obfuscation.
>
> Thanks,
> -Alex
>
> On 8/9/17, 12:45 AM, "Harbs" <ha...@gmail.com> wrote:
>
>> The problem is as follows:
>>
>> Taking textInput as an example, the MXML gets compiled into the following:
>> textInput: {
>> /** @this {com.printui.view.components.PaletteSlider} */
>> get: function() {
>> return this.textInput_;
>> },
>> /** @this {com.printui.view.components.PaletteSlider} */
>> set: function(value) {
>> if (value != this.textInput_) {
>> this.textInput_ = value;
>>
>> this.dispatchEvent(org.apache.flex.events.ValueChangeEvent.createUpdateEve
>> nt(this, 'textInput', null, value));
>> }
>> }
>> },
>>
>> which gets minified to this:
>>
>> yw:{get:r('Nja'),set:function(a){a!=this.Nja&&(this.Nja=a,this.dispatchEve
>> nt(yR(this,iI,null,a)))}}
>>
>> goog has no way of knowing that the original textInput property name is
>> used anywhere so all references to textInput are changed to yw.
>>
>> I think the solution to this is to add @export tags to the
>> Object.defineProperty specification for any property that’s declared or
>> used in the MXML.
>>
>> If localId is used, there might be another option which would be to
>> rename the id to some value that’s one or two characters long. I’m pretty
>> sure that goog will not rename really short property names like that. (We
>> can’t do that for id because it might be used by CSS.)
>>
>> Harbs
>>
>>> On Aug 9, 2017, at 10:25 AM, Harbs <ha...@gmail.com> wrote:
>>>
>>> Here’s a problem I ran into:
>>>
>>> I have a component which has the following:
>>>
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.ap
>>> ache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99bb%7Cfa7b
>>> 1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=FPaamWRAc
>>> t5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0
>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.a
>>> pache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99bb%7Cfa7
>>> b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=FPaamWRA
>>> ct5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0>
>>>
>>> In the script block I have references to disableBead, textInput, etc.
>>>
>>> The instance correctly has properties of disableBead, textInput, etc.,
>>> but every reference to these properties is renamed.
>>>
>>> textInput.addEventListener
>>> becomes:
>>> this.yw.addEventListener
>>>
>>> disableBead.disabled
>>> becomes
>>> this.Jm.disabled
>>>
>>> etc.
>>>
>>> this.yw and this.Jm are both undefined
>>>
>>>> On Aug 9, 2017, at 9:10 AM, Harbs <harbs.lists@gmail.com
>>>> <ma...@gmail.com>> wrote:
>>>>
>>>> I’ll give it a go and see.
>>>>
>>>>> On Aug 9, 2017, at 8:31 AM, Alex Harui <aharui@adobe.com.INVALID
>>>>> <ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com
>>>>> <ma...@gmail.com>> 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 <aharui@adobe.com.INVALID
>>>>>>> <ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com
>>>>>>> <ma...@gmail.com>> 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 <aharui@adobe.com.INVALID
>>>>>>>>> <ma...@adobe.com.INVALID>>
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Package, Class and Method renaming
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hmm. I thought GCC didn't rename those. Anyway, I added back the
@export. See if that works for you and then see if you think there is
enough obfuscation.
Thanks,
-Alex
On 8/9/17, 12:45 AM, "Harbs" <ha...@gmail.com> wrote:
>The problem is as follows:
>
>Taking textInput as an example, the MXML gets compiled into the following:
> textInput: {
> /** @this {com.printui.view.components.PaletteSlider} */
> get: function() {
> return this.textInput_;
> },
> /** @this {com.printui.view.components.PaletteSlider} */
> set: function(value) {
> if (value != this.textInput_) {
> this.textInput_ = value;
>
>this.dispatchEvent(org.apache.flex.events.ValueChangeEvent.createUpdateEve
>nt(this, 'textInput', null, value));
> }
> }
> },
>
>which gets minified to this:
>
>yw:{get:r('Nja'),set:function(a){a!=this.Nja&&(this.Nja=a,this.dispatchEve
>nt(yR(this,iI,null,a)))}}
>
>goog has no way of knowing that the original textInput property name is
>used anywhere so all references to textInput are changed to yw.
>
>I think the solution to this is to add @export tags to the
>Object.defineProperty specification for any property that’s declared or
>used in the MXML.
>
>If localId is used, there might be another option which would be to
>rename the id to some value that’s one or two characters long. I’m pretty
>sure that goog will not rename really short property names like that. (We
>can’t do that for id because it might be used by CSS.)
>
>Harbs
>
>> On Aug 9, 2017, at 10:25 AM, Harbs <ha...@gmail.com> wrote:
>>
>> Here’s a problem I ran into:
>>
>> I have a component which has the following:
>>
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.ap
>>ache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99bb%7Cfa7b
>>1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=FPaamWRAc
>>t5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0
>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.a
>>pache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99bb%7Cfa7
>>b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=FPaamWRA
>>ct5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0>
>>
>> In the script block I have references to disableBead, textInput, etc.
>>
>> The instance correctly has properties of disableBead, textInput, etc.,
>>but every reference to these properties is renamed.
>>
>> textInput.addEventListener
>> becomes:
>> this.yw.addEventListener
>>
>> disableBead.disabled
>> becomes
>> this.Jm.disabled
>>
>> etc.
>>
>> this.yw and this.Jm are both undefined
>>
>>> On Aug 9, 2017, at 9:10 AM, Harbs <harbs.lists@gmail.com
>>><ma...@gmail.com>> wrote:
>>>
>>> I’ll give it a go and see.
>>>
>>>> On Aug 9, 2017, at 8:31 AM, Alex Harui <aharui@adobe.com.INVALID
>>>><ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com
>>>><ma...@gmail.com>> 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 <aharui@adobe.com.INVALID
>>>>>><ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com
>>>>>><ma...@gmail.com>> 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 <aharui@adobe.com.INVALID
>>>>>>>><ma...@adobe.com.INVALID>>
>>>>>>>> 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.
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Package, Class and Method renaming
Posted by Harbs <ha...@gmail.com>.
The problem is as follows:
Taking textInput as an example, the MXML gets compiled into the following:
textInput: {
/** @this {com.printui.view.components.PaletteSlider} */
get: function() {
return this.textInput_;
},
/** @this {com.printui.view.components.PaletteSlider} */
set: function(value) {
if (value != this.textInput_) {
this.textInput_ = value;
this.dispatchEvent(org.apache.flex.events.ValueChangeEvent.createUpdateEvent(this, 'textInput', null, value));
}
}
},
which gets minified to this:
yw:{get:r('Nja'),set:function(a){a!=this.Nja&&(this.Nja=a,this.dispatchEvent(yR(this,iI,null,a)))}}
goog has no way of knowing that the original textInput property name is used anywhere so all references to textInput are changed to yw.
I think the solution to this is to add @export tags to the Object.defineProperty specification for any property that’s declared or used in the MXML.
If localId is used, there might be another option which would be to rename the id to some value that’s one or two characters long. I’m pretty sure that goog will not rename really short property names like that. (We can’t do that for id because it might be used by CSS.)
Harbs
> On Aug 9, 2017, at 10:25 AM, Harbs <ha...@gmail.com> wrote:
>
> Here’s a problem I ran into:
>
> I have a component which has the following:
> https://paste.apache.org/cN1T <https://paste.apache.org/cN1T>
>
> In the script block I have references to disableBead, textInput, etc.
>
> The instance correctly has properties of disableBead, textInput, etc., but every reference to these properties is renamed.
>
> textInput.addEventListener
> becomes:
> this.yw.addEventListener
>
> disableBead.disabled
> becomes
> this.Jm.disabled
>
> etc.
>
> this.yw and this.Jm are both undefined
>
>> On Aug 9, 2017, at 9:10 AM, Harbs <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>
>> I’ll give it a go and see.
>>
>>> On Aug 9, 2017, at 8:31 AM, Alex Harui <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com <ma...@gmail.com>> 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 <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>> 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" <harbs.lists@gmail.com <ma...@gmail.com>> 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 <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>>
>>>>>>> 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.
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Package, Class and Method renaming
Posted by Harbs <ha...@gmail.com>.
Here’s a problem I ran into:
I have a component which has the following:
https://paste.apache.org/cN1T <https://paste.apache.org/cN1T>
In the script block I have references to disableBead, textInput, etc.
The instance correctly has properties of disableBead, textInput, etc., but every reference to these properties is renamed.
textInput.addEventListener
becomes:
this.yw.addEventListener
disableBead.disabled
becomes
this.Jm.disabled
etc.
this.yw and this.Jm are both undefined
> On Aug 9, 2017, at 9:10 AM, Harbs <ha...@gmail.com> wrote:
>
> I’ll give it a go and see.
>
>> On Aug 9, 2017, at 8:31 AM, Alex Harui <ah...@adobe.com.INVALID> 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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID> 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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID>
>>>>>> 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.
>>>>>
>>>>
>>>
>>
>
Re: Package, Class and Method renaming
Posted by Harbs <ha...@gmail.com>.
I’ll give it a go and see.
> On Aug 9, 2017, at 8:31 AM, Alex Harui <ah...@adobe.com.INVALID> 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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID> 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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID>
>>>>> 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.
>>>>
>>>
>>
>
Re: Package, Class and Method renaming
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID> 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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID>
>>>> 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.
>>>
>>
>
Re: Package, Class and Method renaming
Posted by Harbs <ha...@gmail.com>.
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 <ah...@adobe.com.INVALID> 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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID>
>>> 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.
>>
>
Re: Package, Class and Method renaming
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID>
>>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.
>
Re: Package, Class and Method renaming
Posted by Harbs <ha...@gmail.com>.
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 <ah...@adobe.com.INVALID> 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.
Re: Package, Class and Method renaming
Posted by Greg Dove <gr...@gmail.com>.
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 <gr...@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 <ah...@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" <ah...@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" <ha...@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 <ah...@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.
>> >>
>> >
>>
>>
>
Re: Package, Class and Method renaming
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <gr...@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 <ah...@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" <ah...@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" <ha...@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 <ah...@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.
>> >>
>> >
>>
>>
Re: Package, Class and Method renaming
Posted by Greg Dove <gr...@gmail.com>.
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 <ah...@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" <ah...@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" <ha...@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 <ah...@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.
> >>
> >
>
>
Re: Package, Class and Method renaming
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ah...@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" <ha...@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 <ah...@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.
>>
>
Re: Package, Class and Method renaming
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@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 <ah...@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.
>
Re: Package, Class and Method renaming
Posted by Harbs <ha...@gmail.com>.
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 <ah...@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.
Re: Package, Class and Method renaming
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@gmail.com> wrote:
>
>> On Aug 7, 2017, at 5:52 PM, Alex Harui <ah...@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" <ha...@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 <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Package, Class and Method renaming
Posted by Harbs <ha...@gmail.com>.
> On Aug 7, 2017, at 5:52 PM, Alex Harui <ah...@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" <ha...@gmail.com> 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 <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Package, Class and Method renaming
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@gmail.com> 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 <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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
>>>>>
>>>>
>>>
>>
>
Re: Package, Class and Method renaming
Posted by Harbs <ha...@gmail.com>.
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 <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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
>>>>
>>>
>>
>
Re: Package, Class and Method renaming
Posted by Harbs <ha...@gmail.com>.
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 <ah...@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" <ha...@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 <ah...@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" <ha...@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
>>>
>>
>
Re: Package, Class and Method renaming
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@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 <ah...@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" <ha...@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
>>
>
Re: Package, Class and Method renaming
Posted by Harbs <ha...@gmail.com>.
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 <ah...@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" <ha...@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
>
Re: Package, Class and Method renaming
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@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