Re: MXML attributes, minification, and initialization
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" wrote: >Are we using bracket notation for mxml initialization? If so, it looks >like we’re breaking a rule [1]: > > > > > >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. > > > > > >[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 >Sent: Thursday, December 7, 2017 9:19:38 PM >To: dev@royale.apache.org >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" 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: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" wrote: >> >>> >>>> On Dec 6, 2017, at 9:19 PM, Alex Harui >>>>wrote: >>>> >>>> On 12/6/17, 10:01 AM, "Harbs" 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; >&
RE: MXML attributes, minification, and initialization
Are we using bracket notation for mxml initialization? If so, it looks like we’re breaking a rule [1]: 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://developers.google.com/closure/compiler/docs/api-tutorial3#propnames. [1] https://github.com/google/closure-compiler/issues/2758 From: Alex Harui Sent: Thursday, December 7, 2017 9:19:38 PM To: dev@royale.apache.org 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" 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" wrote: > >> >>> On Dec 6, 2017, at 9:19 PM, Alex Harui >>>wrote: >>> >>> On 12/6/17, 10:01 AM, "Harbs" 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
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" 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" wrote: > >> >>> On Dec 6, 2017, at 9:19 PM, Alex Harui >>>wrote: >>> >>> On 12/6/17, 10:01 AM, "Harbs" 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
RE: MXML attributes, minification, and initialization
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://groups.google.com/forum/#!topic/closure-compiler-discuss/grvfL-PIJUQ 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" wrote: > >> On Dec 6, 2017, at 9:19 PM, Alex Harui wrote: >> >> On 12/6/17, 10:01 AM, "Harbs" 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 >>>>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. >>>&
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" wrote:
>
>> On Dec 6, 2017, at 9:19 PM, Alex Harui wrote:
>>
>> On 12/6/17, 10:01 AM, "Harbs" 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
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" 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 inte
Re: MXML attributes, minification, and initialization
> On Dec 6, 2017, at 9:19 PM, Alex Harui wrote:
>
> On 12/6/17, 10:01 AM, "Harbs" 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 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" 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.prot
Re: MXML attributes, minification, and initialization
On 12/6/17, 10:01 AM, "Harbs" 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 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" 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
>>>
>>
>
Re: MXML attributes, minification, and initialization
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 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" 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
>>
>
Re: MXML attributes, minification, and initialization
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" 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
>
RE: MXML attributes, minification, and initialization
>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://paste.apache.org/DSR0 [2] https://paste.apache.org/YtKp
Re: MXML attributes, minification, and initialization
Here’s my reading of the issue:
For some reason, when this code is output, the code gets minified to create a
minified property which is assigned the value of the non-minified one.
Considering a boolean is immutable, changing the value of myProp does not
change the value of of the minified var.
When the variable is not assigned, no minified copy is made, so the original
variable name is always used.
Getters work because the same getter is always called no matter which variable
name is used to access it.
Harbs
> On Dec 6, 2017, at 10:34 AM, Yishay Weiss wrote:
>
> This the js output.
>
>
>
> /**
>
> * @export
>
> * @type {boolean}
>
> */
>
> components.MyComp.prototype.myProp = false;
>
>
>
>
> From: Alex Harui
> Sent: Tuesday, December 5, 2017 7:31:54 PM
> To: dev@royale.apache.org
> Subject: Re: MXML attributes, minification, and initialization
>
> It appears that the component in question is an MXML component, as opposed
> to an AS component. In our AS Components, a public var, like the name
> property in HTTPHeader.as is output in HTTPHeader.js as:
>
> /**
> * @export
> * @type {string}
> */
> org.apache.royale.net.HTTPHeader.prototype.name;
>
> Supposedly, the @export will prevent the name property from being renamed
> by GCC.
>
>
> If you look at your MXML component's .js output, does it have @export in
> the JSDoc for myProp? I'm guessing it doesn't and that is the bug. The
> compiler has to do some interesting things to output fx:Script blocks.
>
> Thanks,
> -Alex
>
>
> On 12/5/17, 1:41 AM, "Yishay Weiss" wrote:
>
>> When I change MyComp to have get/set the result is the following added
>> line, which probably protects the public interface.
>>
>>
>>
>> Object.defineProperties(wf.prototype,{myProp:{get:wf.prototype.ad,set:wf.p
>> rototype.me}})
>>
>>
>>
>>
>> From: Yishay Weiss
>> Sent: Tuesday, December 5, 2017 11:00:40 AM
>> To: dev@royale.apache.org
>> Subject: RE: MXML attributes, minification, and initialization
>>
>> In this [1] I get the following in debug:
>>
>> [org.apache.royale.core.View, 1, '_id', true, '$ID1', 0, 0,
>> [components.MyComp, 2, 'id', true, 'myComp', 'myProp', true
>> And
>> this.myLabel.text = "myProp: " + this.myComp.myProp;
>>
>> And this in release:
>>
>>
>> [W,1,'_id',!0,'$ID1',0,0,[wf,2,'id',!0,'myComp','myProp',!0,
>> And
>>
>> this.myLabel.text='myProp: '+this.myComp.cc
>>
>>
>> So it looks like myComp.myProp is renamed to myComp.cc when reading, but
>> not when writing.
>>
>> If I change the code from
>>
>> public var myProp:Boolean = false;
>> to
>>
>> public var myProp:Boolean;
>>
>> Then I get in release
>>
>>
>> this.myLabel.text='myProp: '+this.myComp.myProp
>>
>> Which has correct behavior.
>>
>> [1]
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
>> m%2Fyishayw%2FExamples%2Ftree%2Frelease_bug&data=02%7C01%7Caharui%40adobe.
>> com%7C07c1ce89c6e648015f0e08d53bc45175%7Cfa7b1b5a7b34438794aed2c178decee1%
>> 7C0%7C0%7C636480636727412967&sdata=yfqv4ORwJio8TJJLzFUSFcCbSWGNJHTQMQb9gT9
>> LJ9o%3D&reserved=0
>>
>> From: Alex Harui<mailto:aha...@adobe.com.INVALID>
>> Sent: Monday, December 4, 2017 7:14 PM
>> To: dev@royale.apache.org<mailto:dev@royale.apache.org>
>> Subject: Re: MXML attributes, minification, and initialization
>>
>> Interesting.
>>
>> What is the generated data structure for that property? How does the
>> generated data structure differ if the property is getter/setter?
>>
>> Thanks,
>> -Alex
>>
>> On 12/4/17, 3:30 AM, "Yishay Weiss" wrote:
>>
>>> We ran into an interesting problem with minification. If you have a
>>> component with an attribute that’s initialized like this:
>>>
>>> public var myProp:Boolean = false;
>>>
>>> and you try to initialize it from mxml () the result
>>> will be myComp == true in debug and myComp == false in release.
>>>
>>> We found 2 ways around that: either don’t initialize (public var
>>> myProp:Boolean) or use get/set methods instead.
>>>
>>> I’m not sure what’s going on there but it’s something to watch out for.
>>>
>>
>
RE: MXML attributes, minification, and initialization
This the js output.
/**
* @export
* @type {boolean}
*/
components.MyComp.prototype.myProp = false;
From: Alex Harui
Sent: Tuesday, December 5, 2017 7:31:54 PM
To: dev@royale.apache.org
Subject: Re: MXML attributes, minification, and initialization
It appears that the component in question is an MXML component, as opposed
to an AS component. In our AS Components, a public var, like the name
property in HTTPHeader.as is output in HTTPHeader.js as:
/**
* @export
* @type {string}
*/
org.apache.royale.net.HTTPHeader.prototype.name;
Supposedly, the @export will prevent the name property from being renamed
by GCC.
If you look at your MXML component's .js output, does it have @export in
the JSDoc for myProp? I'm guessing it doesn't and that is the bug. The
compiler has to do some interesting things to output fx:Script blocks.
Thanks,
-Alex
On 12/5/17, 1:41 AM, "Yishay Weiss" wrote:
>When I change MyComp to have get/set the result is the following added
>line, which probably protects the public interface.
>
>
>
>Object.defineProperties(wf.prototype,{myProp:{get:wf.prototype.ad,set:wf.p
>rototype.me}})
>
>
>
>
>From: Yishay Weiss
>Sent: Tuesday, December 5, 2017 11:00:40 AM
>To: dev@royale.apache.org
>Subject: RE: MXML attributes, minification, and initialization
>
>In this [1] I get the following in debug:
>
>[org.apache.royale.core.View, 1, '_id', true, '$ID1', 0, 0,
>[components.MyComp, 2, 'id', true, 'myComp', 'myProp', true
>And
>this.myLabel.text = "myProp: " + this.myComp.myProp;
>
>And this in release:
>
>
>[W,1,'_id',!0,'$ID1',0,0,[wf,2,'id',!0,'myComp','myProp',!0,
>And
>
>this.myLabel.text='myProp: '+this.myComp.cc
>
>
>So it looks like myComp.myProp is renamed to myComp.cc when reading, but
>not when writing.
>
>If I change the code from
>
>public var myProp:Boolean = false;
>to
>
>public var myProp:Boolean;
>
>Then I get in release
>
>
>this.myLabel.text='myProp: '+this.myComp.myProp
>
>Which has correct behavior.
>
>[1]
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
>m%2Fyishayw%2FExamples%2Ftree%2Frelease_bug&data=02%7C01%7Caharui%40adobe.
>com%7C07c1ce89c6e648015f0e08d53bc45175%7Cfa7b1b5a7b34438794aed2c178decee1%
>7C0%7C0%7C636480636727412967&sdata=yfqv4ORwJio8TJJLzFUSFcCbSWGNJHTQMQb9gT9
>LJ9o%3D&reserved=0
>
>From: Alex Harui<mailto:aha...@adobe.com.INVALID>
>Sent: Monday, December 4, 2017 7:14 PM
>To: dev@royale.apache.org<mailto:dev@royale.apache.org>
>Subject: Re: MXML attributes, minification, and initialization
>
>Interesting.
>
>What is the generated data structure for that property? How does the
>generated data structure differ if the property is getter/setter?
>
>Thanks,
>-Alex
>
>On 12/4/17, 3:30 AM, "Yishay Weiss" wrote:
>
>>We ran into an interesting problem with minification. If you have a
>>component with an attribute that’s initialized like this:
>>
>>public var myProp:Boolean = false;
>>
>>and you try to initialize it from mxml () the result
>>will be myComp == true in debug and myComp == false in release.
>>
>>We found 2 ways around that: either don’t initialize (public var
>>myProp:Boolean) or use get/set methods instead.
>>
>>I’m not sure what’s going on there but it’s something to watch out for.
>>
>
Re: MXML attributes, minification, and initialization
It appears that the component in question is an MXML component, as opposed
to an AS component. In our AS Components, a public var, like the name
property in HTTPHeader.as is output in HTTPHeader.js as:
/**
* @export
* @type {string}
*/
org.apache.royale.net.HTTPHeader.prototype.name;
Supposedly, the @export will prevent the name property from being renamed
by GCC.
If you look at your MXML component's .js output, does it have @export in
the JSDoc for myProp? I'm guessing it doesn't and that is the bug. The
compiler has to do some interesting things to output fx:Script blocks.
Thanks,
-Alex
On 12/5/17, 1:41 AM, "Yishay Weiss" wrote:
>When I change MyComp to have get/set the result is the following added
>line, which probably protects the public interface.
>
>
>
>Object.defineProperties(wf.prototype,{myProp:{get:wf.prototype.ad,set:wf.p
>rototype.me}})
>
>
>
>
>From: Yishay Weiss
>Sent: Tuesday, December 5, 2017 11:00:40 AM
>To: dev@royale.apache.org
>Subject: RE: MXML attributes, minification, and initialization
>
>In this [1] I get the following in debug:
>
>[org.apache.royale.core.View, 1, '_id', true, '$ID1', 0, 0,
>[components.MyComp, 2, 'id', true, 'myComp', 'myProp', true
>And
>this.myLabel.text = "myProp: " + this.myComp.myProp;
>
>And this in release:
>
>
>[W,1,'_id',!0,'$ID1',0,0,[wf,2,'id',!0,'myComp','myProp',!0,
>And
>
>this.myLabel.text='myProp: '+this.myComp.cc
>
>
>So it looks like myComp.myProp is renamed to myComp.cc when reading, but
>not when writing.
>
>If I change the code from
>
>public var myProp:Boolean = false;
>to
>
>public var myProp:Boolean;
>
>Then I get in release
>
>
>this.myLabel.text='myProp: '+this.myComp.myProp
>
>Which has correct behavior.
>
>[1]
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
>m%2Fyishayw%2FExamples%2Ftree%2Frelease_bug&data=02%7C01%7Caharui%40adobe.
>com%7C07c1ce89c6e648015f0e08d53bc45175%7Cfa7b1b5a7b34438794aed2c178decee1%
>7C0%7C0%7C636480636727412967&sdata=yfqv4ORwJio8TJJLzFUSFcCbSWGNJHTQMQb9gT9
>LJ9o%3D&reserved=0
>
>From: Alex Harui<mailto:aha...@adobe.com.INVALID>
>Sent: Monday, December 4, 2017 7:14 PM
>To: dev@royale.apache.org<mailto:dev@royale.apache.org>
>Subject: Re: MXML attributes, minification, and initialization
>
>Interesting.
>
>What is the generated data structure for that property? How does the
>generated data structure differ if the property is getter/setter?
>
>Thanks,
>-Alex
>
>On 12/4/17, 3:30 AM, "Yishay Weiss" wrote:
>
>>We ran into an interesting problem with minification. If you have a
>>component with an attribute that’s initialized like this:
>>
>>public var myProp:Boolean = false;
>>
>>and you try to initialize it from mxml () the result
>>will be myComp == true in debug and myComp == false in release.
>>
>>We found 2 ways around that: either don’t initialize (public var
>>myProp:Boolean) or use get/set methods instead.
>>
>>I’m not sure what’s going on there but it’s something to watch out for.
>>
>
RE: MXML attributes, minification, and initialization
When I change MyComp to have get/set the result is the following added line,
which probably protects the public interface.
Object.defineProperties(wf.prototype,{myProp:{get:wf.prototype.ad,set:wf.prototype.me}})
From: Yishay Weiss
Sent: Tuesday, December 5, 2017 11:00:40 AM
To: dev@royale.apache.org
Subject: RE: MXML attributes, minification, and initialization
In this [1] I get the following in debug:
[org.apache.royale.core.View, 1, '_id', true, '$ID1', 0, 0, [components.MyComp,
2, 'id', true, 'myComp', 'myProp', true
And
this.myLabel.text = "myProp: " + this.myComp.myProp;
And this in release:
[W,1,'_id',!0,'$ID1',0,0,[wf,2,'id',!0,'myComp','myProp',!0,
And
this.myLabel.text='myProp: '+this.myComp.cc
So it looks like myComp.myProp is renamed to myComp.cc when reading, but not
when writing.
If I change the code from
public var myProp:Boolean = false;
to
public var myProp:Boolean;
Then I get in release
this.myLabel.text='myProp: '+this.myComp.myProp
Which has correct behavior.
[1] https://github.com/yishayw/Examples/tree/release_bug
From: Alex Harui<mailto:aha...@adobe.com.INVALID>
Sent: Monday, December 4, 2017 7:14 PM
To: dev@royale.apache.org<mailto:dev@royale.apache.org>
Subject: Re: MXML attributes, minification, and initialization
Interesting.
What is the generated data structure for that property? How does the
generated data structure differ if the property is getter/setter?
Thanks,
-Alex
On 12/4/17, 3:30 AM, "Yishay Weiss" wrote:
>We ran into an interesting problem with minification. If you have a
>component with an attribute that’s initialized like this:
>
>public var myProp:Boolean = false;
>
>and you try to initialize it from mxml () the result
>will be myComp == true in debug and myComp == false in release.
>
>We found 2 ways around that: either don’t initialize (public var
>myProp:Boolean) or use get/set methods instead.
>
>I’m not sure what’s going on there but it’s something to watch out for.
>
RE: MXML attributes, minification, and initialization
In this [1] I get the following in debug: [org.apache.royale.core.View, 1, '_id', true, '$ID1', 0, 0, [components.MyComp, 2, 'id', true, 'myComp', 'myProp', true And this.myLabel.text = "myProp: " + this.myComp.myProp; And this in release: [W,1,'_id',!0,'$ID1',0,0,[wf,2,'id',!0,'myComp','myProp',!0, And this.myLabel.text='myProp: '+this.myComp.cc So it looks like myComp.myProp is renamed to myComp.cc when reading, but not when writing. If I change the code from public var myProp:Boolean = false; to public var myProp:Boolean; Then I get in release this.myLabel.text='myProp: '+this.myComp.myProp Which has correct behavior. [1] https://github.com/yishayw/Examples/tree/release_bug From: Alex Harui<mailto:aha...@adobe.com.INVALID> Sent: Monday, December 4, 2017 7:14 PM To: dev@royale.apache.org<mailto:dev@royale.apache.org> Subject: Re: MXML attributes, minification, and initialization Interesting. What is the generated data structure for that property? How does the generated data structure differ if the property is getter/setter? Thanks, -Alex On 12/4/17, 3:30 AM, "Yishay Weiss" wrote: >We ran into an interesting problem with minification. If you have a >component with an attribute that’s initialized like this: > >public var myProp:Boolean = false; > >and you try to initialize it from mxml () the result >will be myComp == true in debug and myComp == false in release. > >We found 2 ways around that: either don’t initialize (public var >myProp:Boolean) or use get/set methods instead. > >I’m not sure what’s going on there but it’s something to watch out for. >
Re: MXML attributes, minification, and initialization
Interesting. What is the generated data structure for that property? How does the generated data structure differ if the property is getter/setter? Thanks, -Alex On 12/4/17, 3:30 AM, "Yishay Weiss" wrote: >We ran into an interesting problem with minification. If you have a >component with an attribute that’s initialized like this: > >public var myProp:Boolean = false; > >and you try to initialize it from mxml () the result >will be myComp == true in debug and myComp == false in release. > >We found 2 ways around that: either don’t initialize (public var >myProp:Boolean) or use get/set methods instead. > >I’m not sure what’s going on there but it’s something to watch out for. >
