I believe that as long as we use @export we can do both. However, @export does not work for simple vars.
Again, @export does not prevent renaming, it creates an alias/reference. -Alex On 12/14/17, 4:54 AM, "Yishay Weiss" <[email protected]> wrote: >Are we using bracket notation for mxml initialization? If so, it looks >like we’re breaking a rule [1]: > > > ><quote> > >The examples you linked use both dot-syntax and quoted strings to access >components.MyComp.prototype.myProp/myComp["myProp"]. This violates a >compiler assumption in advanced optimizations that you either always use >dot-syntax or always use quoted strings to refer to a given property - >see >https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper >s.google.com%2Fclosure%2Fcompiler%2Fdocs%2Fapi-tutorial3%23propnames&data= >02%7C01%7Caharui%40adobe.com%7Ce6f11c8e2fbf4bc51b0908d542f1c916%7Cfa7b1b5a >7b34438794aed2c178decee1%7C0%7C0%7C636488528580236240&sdata=Fddmnm2%2FDMz6 >xusrJsoroKjh5w0mTYV2p7XUtytKnp4%3D&reserved=0. > ></quote> > > > >[1] >https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co >m%2Fgoogle%2Fclosure-compiler%2Fissues%2F2758&data=02%7C01%7Caharui%40adob >e.com%7Ce6f11c8e2fbf4bc51b0908d542f1c916%7Cfa7b1b5a7b34438794aed2c178decee >1%7C0%7C0%7C636488528580236240&sdata=MQEbe24K7DTVWctRLpIOqxxnzaLc%2BwIWZnf >ytpawgO4%3D&reserved=0 > > > >________________________________ >From: Alex Harui <[email protected]> >Sent: Thursday, December 7, 2017 9:19:38 PM >To: [email protected] >Subject: Re: MXML attributes, minification, and initialization > >Hi Yishay, > >I think you may need to specify the type of myComp. I'm not sure the >closure compiler is going to inference it. > > /** @type components.MyComp */ var myComp = new components.MyComp(); > >HTH, >-Alex > >On 12/7/17, 1:55 AM, "Yishay Weiss" <[email protected]> wrote: > >>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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.g >>o >>ogle.com%2Fforum%2F%23!topic%2Fclosure-compiler-discuss%2FgrvfL-PIJUQ&dat >>a >>=02%7C01%7Caharui%40adobe.com%7Cf70f3bcc117a445fe6e208d53d58b3eb%7Cfa7b1b >>5 >>a7b34438794aed2c178decee1%7C0%7C0%7C636482373571232425&sdata=GECResTzlpw5 >>G >>WZHUgkqgiuMhy2LpN4xiJz1dO66MmM%3D&reserved=0 >> >>From: Alex Harui<mailto:[email protected]> >>Sent: Thursday, December 7, 2017 12:46 AM >>To: [email protected]<mailto:[email protected]> >>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" <[email protected]> wrote: >> >>> >>>> On Dec 6, 2017, at 9:19 PM, Alex Harui <[email protected]> >>>>wrote: >>>> >>>> On 12/6/17, 10:01 AM, "Harbs" <[email protected]> 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 <[email protected]> >>>>>>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" <[email protected]> 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%2Fpas >>>>>>>t >>>>>>>e >>>>>>>.a >>>>>>> pa >>>>>>> >>>>>>> >>>>>>>che.org%2FDSR0&data=02%7C01%7Caharui%40adobe.com%7C7a9997dab7ab4c010 >>>>>>>8 >>>>>>>9 >>>>>>>30 >>>>>>> 8d >>>>>>> >>>>>>> >>>>>>>53c974ac1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364815428510 >>>>>>>0 >>>>>>>8 >>>>>>>41 >>>>>>> 7& >>>>>>> sdata=LCDygcxHaiINRHE7pFbMEzng%2FUXv%2FgntIRpUSpJ2jBk%3D&reserved=0 >>>>>>> [2] >>>>>>> >>>>>>> >>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpas >>>>>>>t >>>>>>>e >>>>>>>.a >>>>>>> pa >>>>>>> >>>>>>> >>>>>>>che.org%2FYtKp&data=02%7C01%7Caharui%40adobe.com%7C7a9997dab7ab4c010 >>>>>>>8 >>>>>>>9 >>>>>>>30 >>>>>>> 8d >>>>>>> >>>>>>> >>>>>>>53c974ac1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364815428510 >>>>>>>0 >>>>>>>8 >>>>>>>41 >>>>>>> 7& >>>>>>> sdata=Q2z8qUTVlYFfBXF7T9KuilRc4AdSd8PZnZF6LRD4QCY%3D&reserved=0 >>>>>>> >>>>>> >>>>> >>>> >>> >> >
