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" <yishayj...@hotmail.com> 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.go
>ogle.com%2Fforum%2F%23!topic%2Fclosure-compiler-discuss%2FgrvfL-PIJUQ&data
>=02%7C01%7Caharui%40adobe.com%7Cf70f3bcc117a445fe6e208d53d58b3eb%7Cfa7b1b5
>a7b34438794aed2c178decee1%7C0%7C0%7C636482373571232425&sdata=GECResTzlpw5G
>WZHUgkqgiuMhy2LpN4xiJz1dO66MmM%3D&reserved=0
>
>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%2Fpast
>>>>>>e
>>>>>>.a
>>>>>> pa
>>>>>>
>>>>>>
>>>>>>che.org%2FDSR0&data=02%7C01%7Caharui%40adobe.com%7C7a9997dab7ab4c0108
>>>>>>9
>>>>>>30
>>>>>> 8d
>>>>>>
>>>>>>
>>>>>>53c974ac1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63648154285100
>>>>>>8
>>>>>>41
>>>>>> 7&
>>>>>> sdata=LCDygcxHaiINRHE7pFbMEzng%2FUXv%2FgntIRpUSpJ2jBk%3D&reserved=0
>>>>>> [2]
>>>>>>
>>>>>>
>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpast
>>>>>>e
>>>>>>.a
>>>>>> pa
>>>>>>
>>>>>>
>>>>>>che.org%2FYtKp&data=02%7C01%7Caharui%40adobe.com%7C7a9997dab7ab4c0108
>>>>>>9
>>>>>>30
>>>>>> 8d
>>>>>>
>>>>>>
>>>>>>53c974ac1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63648154285100
>>>>>>8
>>>>>>41
>>>>>> 7&
>>>>>> sdata=Q2z8qUTVlYFfBXF7T9KuilRc4AdSd8PZnZF6LRD4QCY%3D&reserved=0
>>>>>>
>>>>>
>>>>
>>>
>>
>
