Yes. I think we are saying the same thing. It’s curious that assignment on 
declaration makes a difference.

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


The issue is that all accessors (elsewhere) are renamed to aa instead of myProp 
with the exception of the mxml assignment.

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

> 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%2Fpaste.apa
>> che.org%2FDSR0&data=02%7C01%7Caharui%40adobe.com%7C7a9997dab7ab4c01089308d
>> 53c974ac1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636481542851008417&
>> sdata=LCDygcxHaiINRHE7pFbMEzng%2FUXv%2FgntIRpUSpJ2jBk%3D&reserved=0
>> [2] 
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apa
>> che.org%2FYtKp&data=02%7C01%7Caharui%40adobe.com%7C7a9997dab7ab4c01089308d
>> 53c974ac1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636481542851008417&
>> sdata=Q2z8qUTVlYFfBXF7T9KuilRc4AdSd8PZnZF6LRD4QCY%3D&reserved=0
>> 
> 

Reply via email to