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" <harbs.li...@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 <aha...@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" <harbs.li...@gmail.com> wrote:
>>
>>>
>>>> On Aug 9, 2017, at 11:56 PM, Alex Harui <aha...@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" <harbs.li...@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 <aha...@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" <harbs.li...@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 <harbs.li...@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.li...@gmail.com
>>>>>>>>> <mailto:harbs.li...@gmail.com>> wrote:
>>>>>>>>>
>>>>>>>>> I’ll give it a go and see.
>>>>>>>>>
>>>>>>>>>> On Aug 9, 2017, at 8:31 AM, Alex Harui <aha...@adobe.com.INVALID
>>>>>>>>>> <mailto:aha...@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.li...@gmail.com
>>>>>>>>>> <mailto:harbs.li...@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
>>>>>>>>>>>><aha...@adobe.com.INVALID
>>>>>>>>>>>> <mailto:aha...@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.li...@gmail.com
>>>>>>>>>>>> <mailto:harbs.li...@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
>>>>>>>>>>>>>> <aha...@adobe.com.INVALID
>>>>>>>>>>>>>> <mailto:aha...@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.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
