flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com.INVALID>
Subject Re: Package, Class and Method renaming
Date Sat, 12 Aug 2017 04:13:49 GMT
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" <harbs.lists@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 <aharui@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.lists@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 <aharui@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.lists@gmail.com> wrote:
>>>> 
>>>>> 
>>>>>> On Aug 9, 2017, at 11:56 PM, Alex Harui <aharui@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.lists@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 <aharui@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.lists@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 <harbs.lists@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
>>>>>>>>>>> <mailto:harbs.lists@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
>>>>>>>>>>>> <mailto:aharui@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
>>>>>>>>>>>> <mailto:harbs.lists@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
>>>>>>>>>>>>>> <mailto:aharui@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
>>>>>>>>>>>>>> <mailto:harbs.lists@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
>>>>>>>>>>>>>>>> <mailto:aharui@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.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>

Mime
View raw message