It looks like exported properties are not renamed when they’re not initialized, but are renamed when they are. I think I’ve demonstrated [1] that this results in bugs in the closure compiler. I suggest to see if the closure guys want to fix this or can suggest a workaround.
[1] https://groups.google.com/forum/#!topic/closure-compiler-discuss/grvfL-PIJUQ From: Alex Harui<mailto:aha...@adobe.com.INVALID> Sent: Thursday, December 7, 2017 12:46 AM To: dev@royale.apache.org<mailto:dev@royale.apache.org> Subject: Re: MXML attributes, minification, and initialization I think our choices are to not allow any public vars in MXML Components, or to warn folks if they use public vars that are primitive types. I guess I don't care too much which way folks want to go. Sounds like the first options, I would probably choose the second. Let's see what others think. But I'm pretty certain we'll need to keep @export statements so the properties can be set from MXML. At least for a while. My 2 cents, -Alex On 12/6/17, 1:28 PM, "Harbs" <harbs.li...@gmail.com> wrote: > >> On Dec 6, 2017, at 9:19 PM, Alex Harui <aha...@adobe.com.INVALID> wrote: >> >> On 12/6/17, 10:01 AM, "Harbs" <harbs.li...@gmail.com> wrote: >> >>> Yes. I think we are saying the same thing. It’s curious that assignment >>> on declaration makes a difference. >> >> I don't think we are saying the same thing. Did you actually look at >>the >> output code? > >Yes. I did look at the output code, but it was a few days ago. > >> I'm pretty sure if you assign somewhere other than as an >> initialization value, GCC will use the renamed variable. > >Yup. I was not saying differently. > >>> >>>> But: >>>> MyComp.prototype.aa = false; >>>> MyComp.prototype.myProp = MyComp.prototype.aa; >>> >>> I actually think that it’s the reverse (although there’s no practical >>> difference): >>> >>>> MyComp.prototype.myProp = false; >>>> MyComp.prototype.aa = MyComp.prototype.myProp; >> >> I don't think it is the reverse. GCC is going to use the shortened name >> and never use the exported name as the shortened name is smaller code. > >Agreed. I think you misread what I wrote. I was being a bit pedantic. > >>> >>> The issue is that all accessors (elsewhere) are renamed to aa instead >>>of >>> myProp with the exception of the mxml assignment. >> >> It is ok for things to be renamed as long as the exported reference is a >> reference instead of a value. > >Right. But Booleans, Strings and Numbers will all have this issue. > >>> >>>> Is not going to work. I guess the compiler should either warn on >>>>public >>>> scalar vars, or generate bracket notation for those vars: >>>> >>>> MyComp.protoype["myProp"] = false; >>> >>> How would bracket notation work when myProp is used elsewhere? What’s >>> going to prevent that from being minified? >>> >>> Another approach might be to require that properties assigned via MXML >>> should be getters rather than properties. Then maybe we can avoid >>> @exporting properties. >> >> MXML relies on exported names. The compiler is not smart enough to know >> how things will be renamed. Maybe we can manage that someday, but I >>don't >> want to work on that now. The MXMLDataInterpreter takes the structure >> like Yishay showed upthread: >> >> [org.apache.royale.core.View, 1, '_id', true, '$ID1', 0, 0, >> [components.MyComp, 2, 'id', true, 'myComp', 'myProp', true >> >> >> myProp is referenced by its exported name. > >Sure. I’m not sure how this is a response to what I wrote. I was >suggesting that MXML should require getters rather than public >properties. I’m not sure whether that makes sense, how hard it would be >to implement, or what the implications of doing so will be. > >> Of course I could be wrong... >> >> -Alex >> >> >>>> On Dec 6, 2017, at 7:54 PM, Alex Harui <aha...@adobe.com.INVALID> >>>>wrote: >>>> >>>> In [1], you might need JSDoc for the class function (@constructor, for >>>> example). >>>> >>>> Back to your original test case: If you don't initialize the var >>>>myProp >>>> in your test case, what code is generated for these snippets we've >>>>been >>>> looking at? I would expect that GCC still renames myProp and whatever >>>> code end up initializing it also uses the renamed value. >>>> >>>> @export does not prevent renaming per-se. Instead it builds up a >>>> reference to the same thing. Maybe that's why it doesn't work, scalar >>>> types are by-value and not by-reference. IOW, if you have: >>>> >>>> AS: public function myMethod() {} >>>> >>>> The JS is: >>>> >>>> /** >>>> * @export >>>> */ >>>> MyComp.prototype.myMethod = function() {}; >>>> >>>> Then GCC outputs: >>>> >>>> MyComp.prototype.aa = function() {}; >>>> MyComp.prototype.myMethod = MyComp.prototype.aa; >>>> >>>> GCC will use aa instead of myMethod throughout the minified code. The >>>> myMethod is there for callers from outside the minified code or people >>>> using ["myMethod"] which is what MXML essentially does. >>>> >>>> But: >>>> MyComp.prototype.aa = false; >>>> MyComp.prototype.myProp = MyComp.prototype.aa; >>>> >>>> Is not going to work. I guess the compiler should either warn on >>>>public >>>> scalar vars, or generate bracket notation for those vars: >>>> >>>> MyComp.protoype["myProp"] = false; >>>> >>>> Thoughts? >>>> -Alex >>>> >>>> >>>> On 12/6/17, 2:51 AM, "Yishay Weiss" <yishayj...@hotmail.com> wrote: >>>> >>>>> >>>>> >>>>>> For some reason, when this code is output, the code gets minified >>>>> I guess the question is why the code gets mifinied if it’s annotated >>>>> with >>>>> @export. I’m not sure it’s related but when I compile this [1] file >>>>> with >>>>> gcc I get an internal compiler error [2]. When replacing in [1] >>>>> >>>>> components.MyComp.prototype.myProp = false; >>>>> with >>>>> components.MyComp.prototype.myProp; >>>>> >>>>> I don’t get the error and myProp is correctly not renamed. >>>>> >>>>> [1] >>>>> >>>>> >>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste >>>>>.a >>>>> pa >>>>> >>>>> >>>>>che.org%2FDSR0&data=02%7C01%7Caharui%40adobe.com%7C7a9997dab7ab4c01089 >>>>>30 >>>>> 8d >>>>> >>>>> >>>>>53c974ac1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636481542851008 >>>>>41 >>>>> 7& >>>>> sdata=LCDygcxHaiINRHE7pFbMEzng%2FUXv%2FgntIRpUSpJ2jBk%3D&reserved=0 >>>>> [2] >>>>> >>>>> >>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste >>>>>.a >>>>> pa >>>>> >>>>> >>>>>che.org%2FYtKp&data=02%7C01%7Caharui%40adobe.com%7C7a9997dab7ab4c01089 >>>>>30 >>>>> 8d >>>>> >>>>> >>>>>53c974ac1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636481542851008 >>>>>41 >>>>> 7& >>>>> sdata=Q2z8qUTVlYFfBXF7T9KuilRc4AdSd8PZnZF6LRD4QCY%3D&reserved=0 >>>>> >>>> >>> >> >
