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 Wed, 09 Aug 2017 22:49:04 GMT
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" <harbs.lists@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 <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.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.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%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
>>>>>>>>> <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