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 <aha...@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" <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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
