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? I'm pretty sure if you assign somewhere other than as an
initialization value, GCC will use the renamed variable.
>
>> 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.
>
>
>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.
>
>> 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.
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%7C7a9997dab7ab4c0108930
>>>8d
>>>
>>>53c974ac1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63648154285100841
>>>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%7C7a9997dab7ab4c0108930
>>>8d
>>>
>>>53c974ac1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63648154285100841
>>>7&
>>> sdata=Q2z8qUTVlYFfBXF7T9KuilRc4AdSd8PZnZF6LRD4QCY%3D&reserved=0
>>>
>>
>
