royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yishay Weiss <yishayj...@hotmail.com>
Subject RE: MXML attributes, minification, and initialization
Date Thu, 07 Dec 2017 09:55:35 GMT
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:aharui@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.lists@gmail.com> wrote:

>
>> On Dec 6, 2017, at 9:19 PM, Alex Harui <aharui@adobe.com.INVALID> wrote:
>>
>> On 12/6/17, 10:01 AM, "Harbs" <harbs.lists@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 <aharui@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" <yishayjobs@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%7C7a9997dab7ab4c01089
>>>>>30
>>>>> 8d
>>>>>
>>>>>
>>>>>53c974ac1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636481542851008
>>>>>41
>>>>> 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%7C7a9997dab7ab4c01089
>>>>>30
>>>>> 8d
>>>>>
>>>>>
>>>>>53c974ac1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636481542851008
>>>>>41
>>>>> 7&
>>>>> sdata=Q2z8qUTVlYFfBXF7T9KuilRc4AdSd8PZnZF6LRD4QCY%3D&reserved=0
>>>>>
>>>>
>>>
>>
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message