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]http://kangax.github.io/compat-table/es5/#test-Object/array_literal_extensions_Getter_accessors
<http://kangax.github.io/compat-table/es5/#test-Object/array_literal_extensions_Getter_accessors>
> 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.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.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
