> 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%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
>>>>
>>>
>>
>
