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.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 <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%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.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.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
