You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Alex Harui <ah...@adobe.com.INVALID> on 2018/12/11 08:31:39 UTC
ROYALE_CLASS_INFO, renaming, modules, Objects
I spent some time today trying to get Tour De Flex to run in production mode with the main app and modules being separately minified.
I've fixed a few things here and there, but an interesting issue I ran into has to do with the plain object we use in ROYALE_CLASS_INFO (and will apply to other objects).
The ROYALE_CLASS_INFO is generated on each class and has a "names" property and an optional "interfaces" property. An example is:
org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO = { names: [{ name: 'PanelModel', qName: 'org.apache.royale.html.beads.models.PanelModel', kind: 'class' }], interfaces: [org.apache.royale.core.IBead, org.apache.royale.core.IPanelModel] };
Because the field names are not quoted, then in most output, the field name "interfaces" is renamed and all code referencing this field is renamed as well. This is good because it means that you don't have to download the word "interfaces" once per-class. Instead of 10 characters, it is usually one or two. 100 classes saves you about 900 bytes.
However, it turns out that in Tour De Flex, the main app uses Reflection and Reflection uses a quoted 'interfaces' string and thus, the field name 'interfaces' in ROYALE_CLASS_INFO isn't renamed, but in most modules "interfaces" is renamed since no other code in the module has a quoted string for 'interfaces'. But that means that when a module loads, the Language.is/as won't work since classes in the main app are using "interfaces" but the classes in the module are using some short name.
One solution is to always quote that field in the compiler output and Language is/as so it doesn't get renamed, but that means that field will never get renamed and you lose saving those bytes.
Another is let folks figure out their own workarounds, by adding some code that will prevent the renaming in the modules.
Other ideas are welcome. I'm done for tonight.
Thoughts?
-Alex
Re: ROYALE_CLASS_INFO, renaming, modules, Objects
Posted by Harbs <ha...@gmail.com>.
I’m pretty sure that any names which are a single character (or I think two characters), will not be renamed by the google compiler.
> On Dec 11, 2018, at 11:19 PM, Frost, Andrew <An...@Harman.com> wrote:
>
> So I think what you're saying is that the full build process will result in a minified JS file where e.g. a class with a property called "interfaces" might be changed to "a"; but if we build another module then the minified JS file may have changed the same "interfaces" property into "b"...? hence they're incompatible?
>
> If option A works then it sounds good..
> I don’t know exactly how this is doing it, but a quick look at "Uglify" seems to suggest that this is a problem that's been found/solved before:
> https://www.npmjs.com/package/uglify-js
> has the following note:
> When you compress multiple files using this option, in order for them to work together in the end we need to ensure somehow that one property gets mangled to the same name in all of them. For this, pass --name-cache filename.json and UglifyJS will maintain these mappings in a file which can then be reused.
>
> So that would seem to be the ideal option, so that we can have the compression/minification still but ensuring that everything works together.
>
> Although, just looking at the Google Closure Compiler, perhaps they've not actually got suitable solutions for these issues... https://developers.google.com/closure/compiler/docs/api-tutorial3 has got sections:
> Inconsistent Property Names
> and
> Compiling Two Portions of Code Separately
> neither of which have very practical solutions from our perspective :-(
>
> So turning off this level of optimization, when compiling multiple modules, may be the only solution..?
>
> cheers
>
> Andrew
>
>
> -----Original Message-----
> From: Alex Harui [mailto:aharui@adobe.com.INVALID]
> Sent: 11 December 2018 20:24
> To: dev@royale.apache.org
> Subject: [EXTERNAL] Re: ROYALE_CLASS_INFO, renaming, modules, Objects
>
> Thinking about it more, -js-dynamic-access probably won't help. We don't want to compile our SWCs with that option on and thus turn off minification of these field names always if we can help it.
>
> Even a directive per occurrence won't help either. Whether a field name is renamed is still dependent on what other code is in the compilation.
>
> The problem is better described as trying to find a way to control what field names get renamed in more than one compilation, given that there is pre-transpiled code that allows renaming. When building modules, we already require using Closure Compiler options that output the renaming maps of the main app so that UIBase is given the same short name in all minifications. But there is no way to dictate that for field names as far as I can tell.
>
> -Alex
>
> On 12/11/18, 11:32 AM, "Harbs" <ha...@gmail.com> wrote:
>
> I vote for A.
>
> We can also do B which would require manually changing all access to brackets and quote all names in object literals.
>
> I might be nice to add some comment decorations to enable/disable -js-dynamic-access on a case-by-case basis, but I think it’s reasonable to have a global on/off requirement. I’m already doing this for a library I wrote which has a lot of dynamic data structures which does not survive minification and the results are fine.
>
> My $0.02,
> Harbs
>
>> On Dec 11, 2018, at 8:47 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> IMO, some folks will want to rely on minification of object field names so save space. I think -js-dynamic-access blocks minification.
>>
>> So, to try to pose the problem another way, you can rely on minification object field names if you are building a single-js-file app, but as soon as you start using modules, things may break. So what should we tell folks?
>>
>> A) if you use modules you must turn off minification in objects with -js-dynamic-access
>> B) here are some ways to hack your code so you can still rely on minification
>> C) something else?
>>
>> We can manually rename fields in ROYALE_CLASS_INFO and other structures to make our code less readable in debug mode but save space in release mode, but that does not solve the general case problem. Folks may have other objects in their apps and modules that work until you add some code to one of the projects that changes which object fields get renamed.
>>
>> -Alex
>>
>> On 12/11/18, 9:31 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>> I’m not following why this is the same point.
>>
>> I’m using -js-dynamic-access-unknown-members=true to handle this kind of problem. It works flawlessly…
>>
>> I’d personally argue that true should be the default, but whether the default is true or not, we do have an option to deal with these kinds of data structures.
>>
>>> On Dec 11, 2018, at 6:39 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>
>>> Yes, we can use our own short names in code we generate, but that's not really the point.
>>>
>>> The point is that any plain object field can be renamed based on other code in the compile. So if you just have:
>>>
>>> Var obj:Object = { harbs: 1};
>>> Public static function foo()
>>> {
>>> Trace(obj.harbs);
>>> }
>>>
>>> Use of foo() in one compile may result in harbs being renamed, and another wouldn't. And that poses a problem when data structures are shared between compiled outputs.
>>>
>>> This is a natural way to write AS, but the JS results when minified and shared between app and modules can fail. So what restrictions should we place if any on how folks use plain objects?
>>>
>>> HTH,
>>> -Alex
>>>
>>> On 12/11/18, 7:36 AM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>> I was about to make the same suggestion. We can use “I” for interfaces, “c” for class, “k” for kind, “n” for names. etc.
>>>
>>>> On Dec 11, 2018, at 2:52 PM, Frost, Andrew <An...@Harman.com> wrote:
>>>>
>>>> Hi
>>>>
>>>> Not sure that I fully understand this but would a valid compromise be something where the field name isn't renamed at all automatically, but we just change it in the JS generation code to be "i" rather than "interfaces", and update the Language is/as functions to work with this property name? Not sure whether it would work and I don't know whether the Reflection stuff would then need to change too, but if this is all in the generated outputs and/or the framework's own code then it shouldn't be something that the end user would bother about..
>>>>
>>>> thanks
>>>>
>>>> Andrew
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Alex Harui [mailto:aharui@adobe.com.INVALID]
>>>> Sent: 11 December 2018 08:32
>>>> To: dev@royale.apache.org
>>>> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules, Objects
>>>>
>>>> I spent some time today trying to get Tour De Flex to run in production mode with the main app and modules being separately minified.
>>>>
>>>> I've fixed a few things here and there, but an interesting issue I ran into has to do with the plain object we use in ROYALE_CLASS_INFO (and will apply to other objects).
>>>>
>>>> The ROYALE_CLASS_INFO is generated on each class and has a "names" property and an optional "interfaces" property. An example is:
>>>>
>>>> org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO = { names: [{ name: 'PanelModel', qName: 'org.apache.royale.html.beads.models.PanelModel', kind: 'class' }], interfaces: [org.apache.royale.core.IBead, org.apache.royale.core.IPanelModel] };
>>>>
>>>> Because the field names are not quoted, then in most output, the field name "interfaces" is renamed and all code referencing this field is renamed as well. This is good because it means that you don't have to download the word "interfaces" once per-class. Instead of 10 characters, it is usually one or two. 100 classes saves you about 900 bytes.
>>>>
>>>> However, it turns out that in Tour De Flex, the main app uses Reflection and Reflection uses a quoted 'interfaces' string and thus, the field name 'interfaces' in ROYALE_CLASS_INFO isn't renamed, but in most modules "interfaces" is renamed since no other code in the module has a quoted string for 'interfaces'. But that means that when a module loads, the Language.is/as won't work since classes in the main app are using "interfaces" but the classes in the module are using some short name.
>>>>
>>>> One solution is to always quote that field in the compiler output and Language is/as so it doesn't get renamed, but that means that field will never get renamed and you lose saving those bytes.
>>>>
>>>> Another is let folks figure out their own workarounds, by adding some code that will prevent the renaming in the modules.
>>>>
>>>> Other ideas are welcome. I'm done for tonight.
>>>>
>>>> Thoughts?
>>>> -Alex
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
RE: ROYALE_CLASS_INFO, renaming, modules, Objects
Posted by "Frost, Andrew" <An...@Harman.com>.
So I think what you're saying is that the full build process will result in a minified JS file where e.g. a class with a property called "interfaces" might be changed to "a"; but if we build another module then the minified JS file may have changed the same "interfaces" property into "b"...? hence they're incompatible?
If option A works then it sounds good..
I don’t know exactly how this is doing it, but a quick look at "Uglify" seems to suggest that this is a problem that's been found/solved before:
https://www.npmjs.com/package/uglify-js
has the following note:
When you compress multiple files using this option, in order for them to work together in the end we need to ensure somehow that one property gets mangled to the same name in all of them. For this, pass --name-cache filename.json and UglifyJS will maintain these mappings in a file which can then be reused.
So that would seem to be the ideal option, so that we can have the compression/minification still but ensuring that everything works together.
Although, just looking at the Google Closure Compiler, perhaps they've not actually got suitable solutions for these issues... https://developers.google.com/closure/compiler/docs/api-tutorial3 has got sections:
Inconsistent Property Names
and
Compiling Two Portions of Code Separately
neither of which have very practical solutions from our perspective :-(
So turning off this level of optimization, when compiling multiple modules, may be the only solution..?
cheers
Andrew
-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com.INVALID]
Sent: 11 December 2018 20:24
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: ROYALE_CLASS_INFO, renaming, modules, Objects
Thinking about it more, -js-dynamic-access probably won't help. We don't want to compile our SWCs with that option on and thus turn off minification of these field names always if we can help it.
Even a directive per occurrence won't help either. Whether a field name is renamed is still dependent on what other code is in the compilation.
The problem is better described as trying to find a way to control what field names get renamed in more than one compilation, given that there is pre-transpiled code that allows renaming. When building modules, we already require using Closure Compiler options that output the renaming maps of the main app so that UIBase is given the same short name in all minifications. But there is no way to dictate that for field names as far as I can tell.
-Alex
On 12/11/18, 11:32 AM, "Harbs" <ha...@gmail.com> wrote:
I vote for A.
We can also do B which would require manually changing all access to brackets and quote all names in object literals.
I might be nice to add some comment decorations to enable/disable -js-dynamic-access on a case-by-case basis, but I think it’s reasonable to have a global on/off requirement. I’m already doing this for a library I wrote which has a lot of dynamic data structures which does not survive minification and the results are fine.
My $0.02,
Harbs
> On Dec 11, 2018, at 8:47 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> IMO, some folks will want to rely on minification of object field names so save space. I think -js-dynamic-access blocks minification.
>
> So, to try to pose the problem another way, you can rely on minification object field names if you are building a single-js-file app, but as soon as you start using modules, things may break. So what should we tell folks?
>
> A) if you use modules you must turn off minification in objects with -js-dynamic-access
> B) here are some ways to hack your code so you can still rely on minification
> C) something else?
>
> We can manually rename fields in ROYALE_CLASS_INFO and other structures to make our code less readable in debug mode but save space in release mode, but that does not solve the general case problem. Folks may have other objects in their apps and modules that work until you add some code to one of the projects that changes which object fields get renamed.
>
> -Alex
>
> On 12/11/18, 9:31 AM, "Harbs" <ha...@gmail.com> wrote:
>
> I’m not following why this is the same point.
>
> I’m using -js-dynamic-access-unknown-members=true to handle this kind of problem. It works flawlessly…
>
> I’d personally argue that true should be the default, but whether the default is true or not, we do have an option to deal with these kinds of data structures.
>
>> On Dec 11, 2018, at 6:39 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> Yes, we can use our own short names in code we generate, but that's not really the point.
>>
>> The point is that any plain object field can be renamed based on other code in the compile. So if you just have:
>>
>> Var obj:Object = { harbs: 1};
>> Public static function foo()
>> {
>> Trace(obj.harbs);
>> }
>>
>> Use of foo() in one compile may result in harbs being renamed, and another wouldn't. And that poses a problem when data structures are shared between compiled outputs.
>>
>> This is a natural way to write AS, but the JS results when minified and shared between app and modules can fail. So what restrictions should we place if any on how folks use plain objects?
>>
>> HTH,
>> -Alex
>>
>> On 12/11/18, 7:36 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>> I was about to make the same suggestion. We can use “I” for interfaces, “c” for class, “k” for kind, “n” for names. etc.
>>
>>> On Dec 11, 2018, at 2:52 PM, Frost, Andrew <An...@Harman.com> wrote:
>>>
>>> Hi
>>>
>>> Not sure that I fully understand this but would a valid compromise be something where the field name isn't renamed at all automatically, but we just change it in the JS generation code to be "i" rather than "interfaces", and update the Language is/as functions to work with this property name? Not sure whether it would work and I don't know whether the Reflection stuff would then need to change too, but if this is all in the generated outputs and/or the framework's own code then it shouldn't be something that the end user would bother about..
>>>
>>> thanks
>>>
>>> Andrew
>>>
>>>
>>> -----Original Message-----
>>> From: Alex Harui [mailto:aharui@adobe.com.INVALID]
>>> Sent: 11 December 2018 08:32
>>> To: dev@royale.apache.org
>>> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules, Objects
>>>
>>> I spent some time today trying to get Tour De Flex to run in production mode with the main app and modules being separately minified.
>>>
>>> I've fixed a few things here and there, but an interesting issue I ran into has to do with the plain object we use in ROYALE_CLASS_INFO (and will apply to other objects).
>>>
>>> The ROYALE_CLASS_INFO is generated on each class and has a "names" property and an optional "interfaces" property. An example is:
>>>
>>> org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO = { names: [{ name: 'PanelModel', qName: 'org.apache.royale.html.beads.models.PanelModel', kind: 'class' }], interfaces: [org.apache.royale.core.IBead, org.apache.royale.core.IPanelModel] };
>>>
>>> Because the field names are not quoted, then in most output, the field name "interfaces" is renamed and all code referencing this field is renamed as well. This is good because it means that you don't have to download the word "interfaces" once per-class. Instead of 10 characters, it is usually one or two. 100 classes saves you about 900 bytes.
>>>
>>> However, it turns out that in Tour De Flex, the main app uses Reflection and Reflection uses a quoted 'interfaces' string and thus, the field name 'interfaces' in ROYALE_CLASS_INFO isn't renamed, but in most modules "interfaces" is renamed since no other code in the module has a quoted string for 'interfaces'. But that means that when a module loads, the Language.is/as won't work since classes in the main app are using "interfaces" but the classes in the module are using some short name.
>>>
>>> One solution is to always quote that field in the compiler output and Language is/as so it doesn't get renamed, but that means that field will never get renamed and you lose saving those bytes.
>>>
>>> Another is let folks figure out their own workarounds, by adding some code that will prevent the renaming in the modules.
>>>
>>> Other ideas are welcome. I'm done for tonight.
>>>
>>> Thoughts?
>>> -Alex
>>>
>>
>>
>>
>
>
>
Re: ROYALE_CLASS_INFO, renaming, modules, Objects
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Alex,
it seems to me the perfect solution. To have that contract through
interfaces and using getters/setters is almost all you should need to
separate app from modules and just have a tiny layer of code to tie all,
while continue to work the minified version.
Thanks for working on that
El mié., 12 dic. 2018 a las 1:56, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> FWIW, I found one way to force the minifier to not rename a property,
> which is to create a getter of that name. I tried creating other object
> structures but they didn't work. So the implementation I am testing right
> now is that Module and ModuleLoader have these extra getters to guarantee
> that ROYALE_CLASS_INFO doesn't get renamed in one compilation but not the
> other. That seems PAYG as the cost is paid when you use modules.
>
> Anyone who wants to dig further for a better way to control renaming is
> welcome.
>
> Thanks,
> -Alex
>
> On 12/11/18, 2:33 PM, "Alex Harui" <ah...@adobe.com.INVALID> wrote:
>
> ROYALE_CLASS_INFO is a dynamic object. There is no class definition
> for it, which means that its field names can be renamed.
>
> The whole point of modules is to load classes that aren't in the main
> app so that the main app loads faster. So, if you have
>
> MainApp.mxml
> <mx:Application>
> <mx:ModuleLoader url="MyModule" />
> </mx:Application>
>
> MyModule.mxml
> <mx:Module>
> </mx:Module>
>
> The Language.is function linked into Main app might be checking for
> ROYALE_CLASS_INFO.interfaces and Application class will have a
> ROYALE_CLASS_INFO.interfaces property. But Module might have
> ROYALE_CLASS_INFO.i instead of interfaces. And thus Language.is will not
> work on classes in the module. It depends on what other code is in the
> main app. It appears that use of Reflection.SWC's TypeDefinition in the
> main app tells the minifier to not minify the "interfaces" property. Which
> means that any code an app developer might add to the app could change the
> minification of ROYALE_CLASS_INFO, or any other dynamic object.
>
> I'm trying to figure out why the minifier thinks the use of
> "interfaces" in TypeDefinition matters but other attempts I've tried to
> force the minifier to not rename "interfaces" in the module have not worked.
>
> HTH,
> -Alex
>
> On 12/11/18, 2:19 PM, "Harbs" <ha...@gmail.com> wrote:
>
> I’m still not getting the connection to ROYALE_CLASS_INFO.
>
> Can you explain to me in pseudo-code the problem with that? Why
> does a dynamic object have ROYALE_CLASS_INFO at all?
>
> > On Dec 12, 2018, at 12:16 AM, Alex Harui
> <ah...@adobe.com.INVALID> wrote:
> >
> > I'm not sure why you think it is theoretical. For sure, in TDF,
> the module is not loading because ROYALE_CLASS_INFO is minified differently
> in the main app than the module. Any dynamic objects shared across
> compilations are at risk of being renamed differently. I'm chasing down a
> way to control it.
> >
> > We do have control over the names of classes and properties to
> guarantee they are the same in the app and module. It is just these
> dynamic object keys that we don't yet have control over.
> >
> > We do have the option of defining a class for ROYALE_CLASS_INFO,
> but then it will never minify. I like the fact that it can minify without
> us having to use shortnames. It makes our debug code more readable and
> doesn't waste space in small apps. Adding a class definition for
> ROYALE_CLASS_INFO would further add overhead to small apps.
> >
> > My 2 cents,
> > -Alex
> >
> > On 12/11/18, 2:06 PM, "Harbs" <harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com>> wrote:
> >
> > In fact, in looking through the framework code so far, the
> only place I’ve found variable names not quoted (in JS compatible code) so
> far was in CSSUtils where we have a colorMap. I’m pretty sure the colorMap
> will not work after minification because the color names will not match…
> >
> >> On Dec 12, 2018, at 12:01 AM, Harbs <ha...@gmail.com>
> wrote:
> >>
> >> Hi Carlos,
> >>
> >> We’re only discussing dynamic objects. How many of those do you
> have in your applications? I doubt there’s much difference in performance
> due to minification of dynamic objects.
> >>
> >> In *all* our framework code we have dynamic object
> instantiation in 435 places including TLF, Spark and MX classes. Without
> those packages, I’m estimating it’s a small fraction of that and probably
> most of the dynamic objects are hash maps where they don’t benefit from
> minification anyway.
> >>
> >> The vast majority of the cases where you’re using dynamic
> objects in production code you don’t want the names minified either (i.e.
> API calls and uses of JSON).
> >>
> >> I think that most of this discussion is more theoretical than
> practical considerations.
> >>
> >> My $0.02,
> >> Harbs
> >>
> >>> On Dec 11, 2018, at 11:26 PM, Carlos Rovira <
> carlosrovira@apache.org> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I'm still not using modules. I left that for now until we
> complete the
> >>> first phase in our project, but will be using (hopefully)
> around February.
> >>>
> >>> So right now we're only using minification, that seems not
> only to reduce
> >>> the size of the build, but release mode performs faster, and I
> think is
> >>> due, in part, to minify.
> >>>
> >>> So, IMHO, as a user, I don't like A). Can't think of a
> solution, since is
> >>> not my zone of expertise, and sure you guys found a good
> solution after
> >>> all. Just want to say that as a user, is importante both
> things: have
> >>> modules (and hope we could link as well with routing like
> people do in
> >>> other current techs like React and Angular to get a powerful
> solution for
> >>> SPAs) and have minification, since IMO, the resultant
> js-release build has
> >>> many, many advantages, not only in performance and size but as
> well in
> >>> obfuscation, and for me is like our "binary output code".
> >>>
> >>> Sorry to not be able to give any suggestion, but maybe as well
> an opinion
> >>> of use is as well valuable.
> >>>
> >>> just my 2
> >>>
> >>>
> >>> El mar., 11 dic. 2018 a las 21:24, Alex Harui
> (<ah...@adobe.com.invalid>)
> >>> escribió:
> >>>
> >>>> Thinking about it more, -js-dynamic-access probably won't
> help. We don't
> >>>> want to compile our SWCs with that option on and thus turn
> off minification
> >>>> of these field names always if we can help it.
> >>>>
> >>>> Even a directive per occurrence won't help either. Whether a
> field name
> >>>> is renamed is still dependent on what other code is in the
> compilation.
> >>>>
> >>>> The problem is better described as trying to find a way to
> control what
> >>>> field names get renamed in more than one compilation, given
> that there is
> >>>> pre-transpiled code that allows renaming. When building
> modules, we
> >>>> already require using Closure Compiler options that output
> the renaming
> >>>> maps of the main app so that UIBase is given the same short
> name in all
> >>>> minifications. But there is no way to dictate that for field
> names as far
> >>>> as I can tell.
> >>>>
> >>>> -Alex
> >>>>
> >>>> On 12/11/18, 11:32 AM, "Harbs" <ha...@gmail.com> wrote:
> >>>>
> >>>> I vote for A.
> >>>>
> >>>> We can also do B which would require manually changing all
> access to
> >>>> brackets and quote all names in object literals.
> >>>>
> >>>> I might be nice to add some comment decorations to
> enable/disable
> >>>> -js-dynamic-access on a case-by-case basis, but I think it’s
> reasonable to
> >>>> have a global on/off requirement. I’m already doing this for
> a library I
> >>>> wrote which has a lot of dynamic data structures which does
> not survive
> >>>> minification and the results are fine.
> >>>>
> >>>> My $0.02,
> >>>> Harbs
> >>>>
> >>>>> On Dec 11, 2018, at 8:47 PM, Alex Harui
> <ah...@adobe.com.INVALID>
> >>>> wrote:
> >>>>>
> >>>>> IMO, some folks will want to rely on minification of object
> field
> >>>> names so save space. I think -js-dynamic-access blocks
> minification.
> >>>>>
> >>>>> So, to try to pose the problem another way, you can rely on
> >>>> minification object field names if you are building a
> single-js-file app,
> >>>> but as soon as you start using modules, things may break. So
> what should
> >>>> we tell folks?
> >>>>>
> >>>>> A) if you use modules you must turn off minification in
> objects with
> >>>> -js-dynamic-access
> >>>>> B) here are some ways to hack your code so you can still
> rely on
> >>>> minification
> >>>>> C) something else?
> >>>>>
> >>>>> We can manually rename fields in ROYALE_CLASS_INFO and other
> >>>> structures to make our code less readable in debug mode but
> save space in
> >>>> release mode, but that does not solve the general case
> problem. Folks may
> >>>> have other objects in their apps and modules that work until
> you add some
> >>>> code to one of the projects that changes which object fields
> get renamed.
> >>>>>
> >>>>> -Alex
> >>>>>
> >>>>> On 12/11/18, 9:31 AM, "Harbs" <ha...@gmail.com> wrote:
> >>>>>
> >>>>> I’m not following why this is the same point.
> >>>>>
> >>>>> I’m using -js-dynamic-access-unknown-members=true to handle
> this
> >>>> kind of problem. It works flawlessly…
> >>>>>
> >>>>> I’d personally argue that true should be the default, but
> whether
> >>>> the default is true or not, we do have an option to deal with
> these kinds
> >>>> of data structures.
> >>>>>
> >>>>>> On Dec 11, 2018, at 6:39 PM, Alex Harui
> <ah...@adobe.com.INVALID>
> >>>> wrote:
> >>>>>>
> >>>>>> Yes, we can use our own short names in code we generate,
> but that's
> >>>> not really the point.
> >>>>>>
> >>>>>> The point is that any plain object field can be renamed
> based on
> >>>> other code in the compile. So if you just have:
> >>>>>>
> >>>>>> Var obj:Object = { harbs: 1};
> >>>>>> Public static function foo()
> >>>>>> {
> >>>>>> Trace(obj.harbs);
> >>>>>> }
> >>>>>>
> >>>>>> Use of foo() in one compile may result in harbs being
> renamed, and
> >>>> another wouldn't. And that poses a problem when data
> structures are shared
> >>>> between compiled outputs.
> >>>>>>
> >>>>>> This is a natural way to write AS, but the JS results when
> minified
> >>>> and shared between app and modules can fail. So what
> restrictions should
> >>>> we place if any on how folks use plain objects?
> >>>>>>
> >>>>>> HTH,
> >>>>>> -Alex
> >>>>>>
> >>>>>> On 12/11/18, 7:36 AM, "Harbs" <ha...@gmail.com>
> wrote:
> >>>>>>
> >>>>>> I was about to make the same suggestion. We can use “I” for
> >>>> interfaces, “c” for class, “k” for kind, “n” for names. etc.
> >>>>>>
> >>>>>>> On Dec 11, 2018, at 2:52 PM, Frost, Andrew
> <An...@Harman.com>
> >>>> wrote:
> >>>>>>>
> >>>>>>> Hi
> >>>>>>>
> >>>>>>> Not sure that I fully understand this but would a valid
> compromise
> >>>> be something where the field name isn't renamed at all
> automatically, but
> >>>> we just change it in the JS generation code to be "i" rather
> than
> >>>> "interfaces", and update the Language is/as functions to work
> with this
> >>>> property name? Not sure whether it would work and I don't
> know whether the
> >>>> Reflection stuff would then need to change too, but if this
> is all in the
> >>>> generated outputs and/or the framework's own code then it
> shouldn't be
> >>>> something that the end user would bother about..
> >>>>>>>
> >>>>>>> thanks
> >>>>>>>
> >>>>>>> Andrew
> >>>>>>>
> >>>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Alex Harui [mailto:aharui@adobe.com.INVALID]
> >>>>>>> Sent: 11 December 2018 08:32
> >>>>>>> To: dev@royale.apache.org
> >>>>>>> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules,
> Objects
> >>>>>>>
> >>>>>>> I spent some time today trying to get Tour De Flex to run
> in
> >>>> production mode with the main app and modules being
> separately minified.
> >>>>>>>
> >>>>>>> I've fixed a few things here and there, but an interesting
> issue I
> >>>> ran into has to do with the plain object we use in
> ROYALE_CLASS_INFO (and
> >>>> will apply to other objects).
> >>>>>>>
> >>>>>>> The ROYALE_CLASS_INFO is generated on each class and has a
> "names"
> >>>> property and an optional "interfaces" property. An example
> is:
> >>>>>>>
> >>>>>>>
> >>>>
> org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO
> >>>> = { names: [{ name: 'PanelModel', qName:
> >>>> 'org.apache.royale.html.beads.models.PanelModel', kind:
> 'class' }],
> >>>> interfaces: [org.apache.royale.core.IBead,
> >>>> org.apache.royale.core.IPanelModel] };
> >>>>>>>
> >>>>>>> Because the field names are not quoted, then in most
> output, the
> >>>> field name "interfaces" is renamed and all code referencing
> this field is
> >>>> renamed as well. This is good because it means that you
> don't have to
> >>>> download the word "interfaces" once per-class. Instead of 10
> characters, it
> >>>> is usually one or two. 100 classes saves you about 900 bytes.
> >>>>>>>
> >>>>>>> However, it turns out that in Tour De Flex, the main app
> uses
> >>>> Reflection and Reflection uses a quoted 'interfaces' string
> and thus, the
> >>>> field name 'interfaces' in ROYALE_CLASS_INFO isn't renamed,
> but in most
> >>>> modules "interfaces" is renamed since no other code in the
> module has a
> >>>> quoted string for 'interfaces'. But that means that when a
> module loads,
> >>>> the Language.is/as won't work since classes in the main app
> are using
> >>>> "interfaces" but the classes in the module are using some
> short name.
> >>>>>>>
> >>>>>>> One solution is to always quote that field in the compiler
> output
> >>>> and Language is/as so it doesn't get renamed, but that means
> that field
> >>>> will never get renamed and you lose saving those bytes.
> >>>>>>>
> >>>>>>> Another is let folks figure out their own workarounds, by
> adding
> >>>> some code that will prevent the renaming in the modules.
> >>>>>>>
> >>>>>>> Other ideas are welcome. I'm done for tonight.
> >>>>>>>
> >>>>>>> Thoughts?
> >>>>>>> -Alex
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> --
> >>> Carlos Rovira
> >>>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cd633bd078e4b49dffef008d65fb89f4c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636801643904081218&sdata=qQ9i5ZVGLKLvJimX2KhDJOEGPdywq5Ske7IAMGcO2Xo%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cd633bd078e4b49dffef008d65fb89f4c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636801643904081218&sdata=qQ9i5ZVGLKLvJimX2KhDJOEGPdywq5Ske7IAMGcO2Xo%3D&reserved=0
> >
>
>
>
>
>
--
<http://www.codeoscopic.com>
Carlos Rovira
Presidente Ejecutivo
M: +34 607 22 60 05
http://www.codeoscopic.com
Conócenos en 1 minuto! <https://avant2.es/#video>
AVISO LEGAL: La información contenida en este correo electrónico, y en su
caso en los documentos adjuntos, es información privilegiada para uso
exclusivo de la persona y/o personas a las que va dirigido. No está
permitido el acceso a este mensaje a cualquier otra persona distinta a los
indicados. Si Usted no es uno de los destinatarios, cualquier duplicación,
reproducción, distribución, así como cualquier uso de la información
contenida en él o cualquiera otra acción u omisión tomada en relación con
el mismo, está prohibida y puede ser ilegal. En dicho caso, por favor,
notifíquelo al remitente y proceda a la eliminación de este correo
electrónico, así como de sus adjuntos si los hubiere. En cumplimiento de la
legislación española vigente en materia de protección de datos de carácter
personal y del RGPD 679/2016 le informamos que sus datos están siendo
objeto de tratamiento por parte de CODEOSCOPIC S.A. con CIFA85677342, con
la finalidad del mantenimiento y gestión de relaciones comerciales y
administrativas. La base jurídica del tratamiento es el interés legítimo de
la empresa. No se prevén cesiones de sus datos, salvo que exista una
obligación legal. Para ejercitar sus derechos puede dirigirse a CODEOSCOPIC
S.A., domiciliada enPaseo de la Habana, 9-11, 28036 de Madrid (MADRID), o
bien por email adpd@codeoscopic.com, con el fin de ejercer sus derechos de
acceso, rectificación, supresión (derecho al olvido), limitación de
tratamiento, portabilidad de los datos, oposición, y a no ser objeto de
decisiones automatizadas, indicando como Asunto: “Derechos Ley Protección
de Datos”, y adjuntando fotocopia de su DNI. Delegado de protección de
datos:dpd@codeoscopic.com
Re: ROYALE_CLASS_INFO, renaming, modules, Objects
Posted by Alex Harui <ah...@adobe.com.INVALID>.
FWIW, I found one way to force the minifier to not rename a property, which is to create a getter of that name. I tried creating other object structures but they didn't work. So the implementation I am testing right now is that Module and ModuleLoader have these extra getters to guarantee that ROYALE_CLASS_INFO doesn't get renamed in one compilation but not the other. That seems PAYG as the cost is paid when you use modules.
Anyone who wants to dig further for a better way to control renaming is welcome.
Thanks,
-Alex
On 12/11/18, 2:33 PM, "Alex Harui" <ah...@adobe.com.INVALID> wrote:
ROYALE_CLASS_INFO is a dynamic object. There is no class definition for it, which means that its field names can be renamed.
The whole point of modules is to load classes that aren't in the main app so that the main app loads faster. So, if you have
MainApp.mxml
<mx:Application>
<mx:ModuleLoader url="MyModule" />
</mx:Application>
MyModule.mxml
<mx:Module>
</mx:Module>
The Language.is function linked into Main app might be checking for ROYALE_CLASS_INFO.interfaces and Application class will have a ROYALE_CLASS_INFO.interfaces property. But Module might have ROYALE_CLASS_INFO.i instead of interfaces. And thus Language.is will not work on classes in the module. It depends on what other code is in the main app. It appears that use of Reflection.SWC's TypeDefinition in the main app tells the minifier to not minify the "interfaces" property. Which means that any code an app developer might add to the app could change the minification of ROYALE_CLASS_INFO, or any other dynamic object.
I'm trying to figure out why the minifier thinks the use of "interfaces" in TypeDefinition matters but other attempts I've tried to force the minifier to not rename "interfaces" in the module have not worked.
HTH,
-Alex
On 12/11/18, 2:19 PM, "Harbs" <ha...@gmail.com> wrote:
I’m still not getting the connection to ROYALE_CLASS_INFO.
Can you explain to me in pseudo-code the problem with that? Why does a dynamic object have ROYALE_CLASS_INFO at all?
> On Dec 12, 2018, at 12:16 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> I'm not sure why you think it is theoretical. For sure, in TDF, the module is not loading because ROYALE_CLASS_INFO is minified differently in the main app than the module. Any dynamic objects shared across compilations are at risk of being renamed differently. I'm chasing down a way to control it.
>
> We do have control over the names of classes and properties to guarantee they are the same in the app and module. It is just these dynamic object keys that we don't yet have control over.
>
> We do have the option of defining a class for ROYALE_CLASS_INFO, but then it will never minify. I like the fact that it can minify without us having to use shortnames. It makes our debug code more readable and doesn't waste space in small apps. Adding a class definition for ROYALE_CLASS_INFO would further add overhead to small apps.
>
> My 2 cents,
> -Alex
>
> On 12/11/18, 2:06 PM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>
> In fact, in looking through the framework code so far, the only place I’ve found variable names not quoted (in JS compatible code) so far was in CSSUtils where we have a colorMap. I’m pretty sure the colorMap will not work after minification because the color names will not match…
>
>> On Dec 12, 2018, at 12:01 AM, Harbs <ha...@gmail.com> wrote:
>>
>> Hi Carlos,
>>
>> We’re only discussing dynamic objects. How many of those do you have in your applications? I doubt there’s much difference in performance due to minification of dynamic objects.
>>
>> In *all* our framework code we have dynamic object instantiation in 435 places including TLF, Spark and MX classes. Without those packages, I’m estimating it’s a small fraction of that and probably most of the dynamic objects are hash maps where they don’t benefit from minification anyway.
>>
>> The vast majority of the cases where you’re using dynamic objects in production code you don’t want the names minified either (i.e. API calls and uses of JSON).
>>
>> I think that most of this discussion is more theoretical than practical considerations.
>>
>> My $0.02,
>> Harbs
>>
>>> On Dec 11, 2018, at 11:26 PM, Carlos Rovira <ca...@apache.org> wrote:
>>>
>>> Hi,
>>>
>>> I'm still not using modules. I left that for now until we complete the
>>> first phase in our project, but will be using (hopefully) around February.
>>>
>>> So right now we're only using minification, that seems not only to reduce
>>> the size of the build, but release mode performs faster, and I think is
>>> due, in part, to minify.
>>>
>>> So, IMHO, as a user, I don't like A). Can't think of a solution, since is
>>> not my zone of expertise, and sure you guys found a good solution after
>>> all. Just want to say that as a user, is importante both things: have
>>> modules (and hope we could link as well with routing like people do in
>>> other current techs like React and Angular to get a powerful solution for
>>> SPAs) and have minification, since IMO, the resultant js-release build has
>>> many, many advantages, not only in performance and size but as well in
>>> obfuscation, and for me is like our "binary output code".
>>>
>>> Sorry to not be able to give any suggestion, but maybe as well an opinion
>>> of use is as well valuable.
>>>
>>> just my 2
>>>
>>>
>>> El mar., 11 dic. 2018 a las 21:24, Alex Harui (<ah...@adobe.com.invalid>)
>>> escribió:
>>>
>>>> Thinking about it more, -js-dynamic-access probably won't help. We don't
>>>> want to compile our SWCs with that option on and thus turn off minification
>>>> of these field names always if we can help it.
>>>>
>>>> Even a directive per occurrence won't help either. Whether a field name
>>>> is renamed is still dependent on what other code is in the compilation.
>>>>
>>>> The problem is better described as trying to find a way to control what
>>>> field names get renamed in more than one compilation, given that there is
>>>> pre-transpiled code that allows renaming. When building modules, we
>>>> already require using Closure Compiler options that output the renaming
>>>> maps of the main app so that UIBase is given the same short name in all
>>>> minifications. But there is no way to dictate that for field names as far
>>>> as I can tell.
>>>>
>>>> -Alex
>>>>
>>>> On 12/11/18, 11:32 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>
>>>> I vote for A.
>>>>
>>>> We can also do B which would require manually changing all access to
>>>> brackets and quote all names in object literals.
>>>>
>>>> I might be nice to add some comment decorations to enable/disable
>>>> -js-dynamic-access on a case-by-case basis, but I think it’s reasonable to
>>>> have a global on/off requirement. I’m already doing this for a library I
>>>> wrote which has a lot of dynamic data structures which does not survive
>>>> minification and the results are fine.
>>>>
>>>> My $0.02,
>>>> Harbs
>>>>
>>>>> On Dec 11, 2018, at 8:47 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>> wrote:
>>>>>
>>>>> IMO, some folks will want to rely on minification of object field
>>>> names so save space. I think -js-dynamic-access blocks minification.
>>>>>
>>>>> So, to try to pose the problem another way, you can rely on
>>>> minification object field names if you are building a single-js-file app,
>>>> but as soon as you start using modules, things may break. So what should
>>>> we tell folks?
>>>>>
>>>>> A) if you use modules you must turn off minification in objects with
>>>> -js-dynamic-access
>>>>> B) here are some ways to hack your code so you can still rely on
>>>> minification
>>>>> C) something else?
>>>>>
>>>>> We can manually rename fields in ROYALE_CLASS_INFO and other
>>>> structures to make our code less readable in debug mode but save space in
>>>> release mode, but that does not solve the general case problem. Folks may
>>>> have other objects in their apps and modules that work until you add some
>>>> code to one of the projects that changes which object fields get renamed.
>>>>>
>>>>> -Alex
>>>>>
>>>>> On 12/11/18, 9:31 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>
>>>>> I’m not following why this is the same point.
>>>>>
>>>>> I’m using -js-dynamic-access-unknown-members=true to handle this
>>>> kind of problem. It works flawlessly…
>>>>>
>>>>> I’d personally argue that true should be the default, but whether
>>>> the default is true or not, we do have an option to deal with these kinds
>>>> of data structures.
>>>>>
>>>>>> On Dec 11, 2018, at 6:39 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>> wrote:
>>>>>>
>>>>>> Yes, we can use our own short names in code we generate, but that's
>>>> not really the point.
>>>>>>
>>>>>> The point is that any plain object field can be renamed based on
>>>> other code in the compile. So if you just have:
>>>>>>
>>>>>> Var obj:Object = { harbs: 1};
>>>>>> Public static function foo()
>>>>>> {
>>>>>> Trace(obj.harbs);
>>>>>> }
>>>>>>
>>>>>> Use of foo() in one compile may result in harbs being renamed, and
>>>> another wouldn't. And that poses a problem when data structures are shared
>>>> between compiled outputs.
>>>>>>
>>>>>> This is a natural way to write AS, but the JS results when minified
>>>> and shared between app and modules can fail. So what restrictions should
>>>> we place if any on how folks use plain objects?
>>>>>>
>>>>>> HTH,
>>>>>> -Alex
>>>>>>
>>>>>> On 12/11/18, 7:36 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>
>>>>>> I was about to make the same suggestion. We can use “I” for
>>>> interfaces, “c” for class, “k” for kind, “n” for names. etc.
>>>>>>
>>>>>>> On Dec 11, 2018, at 2:52 PM, Frost, Andrew <An...@Harman.com>
>>>> wrote:
>>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> Not sure that I fully understand this but would a valid compromise
>>>> be something where the field name isn't renamed at all automatically, but
>>>> we just change it in the JS generation code to be "i" rather than
>>>> "interfaces", and update the Language is/as functions to work with this
>>>> property name? Not sure whether it would work and I don't know whether the
>>>> Reflection stuff would then need to change too, but if this is all in the
>>>> generated outputs and/or the framework's own code then it shouldn't be
>>>> something that the end user would bother about..
>>>>>>>
>>>>>>> thanks
>>>>>>>
>>>>>>> Andrew
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Alex Harui [mailto:aharui@adobe.com.INVALID]
>>>>>>> Sent: 11 December 2018 08:32
>>>>>>> To: dev@royale.apache.org
>>>>>>> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules, Objects
>>>>>>>
>>>>>>> I spent some time today trying to get Tour De Flex to run in
>>>> production mode with the main app and modules being separately minified.
>>>>>>>
>>>>>>> I've fixed a few things here and there, but an interesting issue I
>>>> ran into has to do with the plain object we use in ROYALE_CLASS_INFO (and
>>>> will apply to other objects).
>>>>>>>
>>>>>>> The ROYALE_CLASS_INFO is generated on each class and has a "names"
>>>> property and an optional "interfaces" property. An example is:
>>>>>>>
>>>>>>>
>>>> org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO
>>>> = { names: [{ name: 'PanelModel', qName:
>>>> 'org.apache.royale.html.beads.models.PanelModel', kind: 'class' }],
>>>> interfaces: [org.apache.royale.core.IBead,
>>>> org.apache.royale.core.IPanelModel] };
>>>>>>>
>>>>>>> Because the field names are not quoted, then in most output, the
>>>> field name "interfaces" is renamed and all code referencing this field is
>>>> renamed as well. This is good because it means that you don't have to
>>>> download the word "interfaces" once per-class. Instead of 10 characters, it
>>>> is usually one or two. 100 classes saves you about 900 bytes.
>>>>>>>
>>>>>>> However, it turns out that in Tour De Flex, the main app uses
>>>> Reflection and Reflection uses a quoted 'interfaces' string and thus, the
>>>> field name 'interfaces' in ROYALE_CLASS_INFO isn't renamed, but in most
>>>> modules "interfaces" is renamed since no other code in the module has a
>>>> quoted string for 'interfaces'. But that means that when a module loads,
>>>> the Language.is/as won't work since classes in the main app are using
>>>> "interfaces" but the classes in the module are using some short name.
>>>>>>>
>>>>>>> One solution is to always quote that field in the compiler output
>>>> and Language is/as so it doesn't get renamed, but that means that field
>>>> will never get renamed and you lose saving those bytes.
>>>>>>>
>>>>>>> Another is let folks figure out their own workarounds, by adding
>>>> some code that will prevent the renaming in the modules.
>>>>>>>
>>>>>>> Other ideas are welcome. I'm done for tonight.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>> -Alex
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Carlos Rovira
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cd633bd078e4b49dffef008d65fb89f4c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636801643904081218&sdata=qQ9i5ZVGLKLvJimX2KhDJOEGPdywq5Ske7IAMGcO2Xo%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cd633bd078e4b49dffef008d65fb89f4c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636801643904081218&sdata=qQ9i5ZVGLKLvJimX2KhDJOEGPdywq5Ske7IAMGcO2Xo%3D&reserved=0>
Re: ROYALE_CLASS_INFO, renaming, modules, Objects
Posted by Alex Harui <ah...@adobe.com.INVALID>.
OK, thanks for the alert.
I'm not sure anyone is actually using JSONReviver right now, but I will try to remember to look for uses of info() elsewhere and update them.
-Alex
On 12/13/18, 12:57 PM, "Greg Dove" <gr...@gmail.com> wrote:
Alex, the compiler change you made recently for some things to 'prevent
renaming' for modules may require changes in related support classes in the
framework. I had to make a change in ClassAliasBead to have it continue to
work in release mode. I did that to get it working again because we are
using it and I could verify, but I see now that JSONReviver will likely
need the same change. I'm not using that so not in a position to verify it
and others. You probably know all the locations well in the framework that
relate to the compiler changes and I'm guessing you are in a better
position to test them (because I only used the alias stuff so far)... just
letting you know in case they may need the same treatment...
On Thu, Dec 13, 2018 at 2:11 PM Alex Harui <ah...@adobe.com.invalid> wrote:
> Closure Compiler will rename (to a short name) any object and property on
> any object that isn't marked as "don’t rename" via several techniques:
>
> 1) Externs
> 2) @export
> 3) bracket syntax (i.e. obj["dontRenameThisProperty"])
> 4) having a getter and/or setter of the same name elsewhere in the
> compilation
>
> By default, all Royale public and protected properties are marked as
> @export so they will never be renamed. That's what you want when
> deserializing network data or when folks might be using bracket syntax to
> access properties.
>
> It "should be" ok for us and others to use plain objects than can be
> minified/renamed if needed. The key is being able to control what gets
> minified. I think #4 gives a way to control it.
>
> HTH,
> -Alex
>
> On 12/12/18, 9:10 AM, "Carlos Rovira" <ca...@codeoscopic.com>
> wrote:
>
> Hi Alex,
>
> what do you mean with "prevent renaming"? there's some process that
> implies a renaming? and renaming of what? the nested properties?
>
> thanks
>
>
>
> El mié., 12 dic. 2018 a las 17:21, Alex Harui
> (<ah...@adobe.com.invalid>)
> escribió:
>
> > Using a plain object allows renaming. Using a class definition
> prevents
> > renaming.
> >
> > Using shortnames in plain objects prevents renaming but is, IMO, a
> bad
> > practice. Why make our code harder to read? It isn't just in the
> data
> > structure, but in the code that reads it.
> >
> > -Alex
> >
> > On 12/12/18, 2:34 AM, "Carlos Rovira" <carlos.rovira@codeoscopic.com
> >
> > wrote:
> >
> > Harb,
> >
> > That seems ok, but moreover...why don't we have a class
> definition
> > instead
> > a plain object, somethings like RoyaleClassInfo.as?
> > Since Royale tries to enforce typing, I think using a plain
> object for
> > royale class info, doesn't seems the most proper way to me
> >
> > thanks
> >
> >
> >
> > El mié., 12 dic. 2018 a las 11:23, Harbs (<harbs.lists@gmail.com
> >)
> > escribió:
> >
> > > Right, but I thought we already suggested single character
> names for
> > the
> > > ROYALE_CLASS_INFO object.
> > >
> > > To take one example:
> > >
> >
> org.apache.royale.html.supportClasses.Viewport.prototype.ROYALE_CLASS_INFO
> > > = { names: [{ name: 'Viewport', qName:
> > > 'org.apache.royale.html.supportClasses.Viewport', kind:
> 'class' }],
> > > interfaces: [org.apache.royale.core.IBead,
> > > org.apache.royale.core.IViewport] };
> > >
> > > That would become:
> > >
> >
> org.apache.royale.html.supportClasses.Viewport.prototype.ROYALE_CLASS_INFO
> > > = { n: [{ n: 'Viewport', q:
> > > 'org.apache.royale.html.supportClasses.Viewport', k: 'class'
> }], i:
> > > [org.apache.royale.core.IBead,
> org.apache.royale.core.IViewport] };
> > >
> > > I’m pretty sure that’s enough to prevent renaming (because the
> > closure
> > > compiler does not rename single character variable names). If
> I’m
> > wrong, we
> > > could always output something like this:
> > >
> > >
> >
> org.apache.royale.html.supportClasses.Viewport.prototype.ROYALE_CLASS_INFO
> > > = { 'n': [{ 'n': 'Viewport', 'q':
> > > 'org.apache.royale.html.supportClasses.Viewport', 'k': 'class'
> }],
> > 'i':
> > > [org.apache.royale.core.IBead,
> org.apache.royale.core.IViewport] };
> > >
> > > Am I missing something?
> > > Harbs
> > >
> > > > On Dec 12, 2018, at 12:32 AM, Alex Harui
> <aharui@adobe.com.INVALID
> > >
> > > wrote:
> > > >
> > > > ROYALE_CLASS_INFO is a dynamic object. There is no class
> > definition for
> > > it, which means that its field names can be renamed.
> > > >
> > > > The whole point of modules is to load classes that aren't in
> the
> > main
> > > app so that the main app loads faster. So, if you have
> > > >
> > > > MainApp.mxml
> > > > <mx:Application>
> > > > <mx:ModuleLoader url="MyModule" />
> > > > </mx:Application>
> > > >
> > > > MyModule.mxml
> > > > <mx:Module>
> > > > </mx:Module>
> > > >
> > > > The Language.is <
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flanguage.is%2F&data=02%7C01%7Caharui%40adobe.com%7C00fc453c2c24467304ff08d6613da337%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636803314718255897&sdata=PI7PBL82NhfSixYGtLpawfS7LkvPw4KJBPmo5P2ZAH4%3D&reserved=0
> >
> > function linked into Main app
> > > might be checking for ROYALE_CLASS_INFO.interfaces and
> Application
> > class
> > > will have a ROYALE_CLASS_INFO.interfaces property. But Module
> might
> > have
> > > ROYALE_CLASS_INFO.i instead of interfaces. And thus
> Language.is <
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flanguage.is%2F&data=02%7C01%7Caharui%40adobe.com%7C00fc453c2c24467304ff08d6613da337%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636803314718255897&sdata=PI7PBL82NhfSixYGtLpawfS7LkvPw4KJBPmo5P2ZAH4%3D&reserved=0
> >
> > will not work on classes in the module. It depends
> > > on what other code is in the main app. It appears that use of
> > > Reflection.SWC's TypeDefinition in the main app tells the
> minifier
> > to not
> > > minify the "interfaces" property. Which means that any code
> an app
> > > developer might add to the app could change the minification of
> > > ROYALE_CLASS_INFO, or any other dynamic object.
> > > >
> > > > I'm trying to figure out why the minifier thinks the use of
> > "interfaces"
> > > in TypeDefinition matters but other attempts I've tried to
> force the
> > > minifier to not rename "interfaces" in the module have not
> worked.
> > > >
> > > > HTH,
> > > > -Alex
> > > >
> > > > On 12/11/18, 2:19 PM, "Harbs" <harbs.lists@gmail.com
> <mailto:
> > > harbs.lists@gmail.com>> wrote:
> > > >
> > > > I’m still not getting the connection to ROYALE_CLASS_INFO.
> > > >
> > > > Can you explain to me in pseudo-code the problem with
> that? Why
> > does
> > > a dynamic object have ROYALE_CLASS_INFO at all?
> > > >
> > > >> On Dec 12, 2018, at 12:16 AM, Alex Harui
> <aharui@adobe.com.INVALID
> > >
> > > wrote:
> > > >>
> > > >> I'm not sure why you think it is theoretical. For sure, in
> TDF,
> > the
> > > module is not loading because ROYALE_CLASS_INFO is minified
> > differently in
> > > the main app than the module. Any dynamic objects shared across
> > > compilations are at risk of being renamed differently. I'm
> chasing
> > down a
> > > way to control it.
> > > >>
> > > >> We do have control over the names of classes and properties
> to
> > > guarantee they are the same in the app and module. It is just
> these
> > > dynamic object keys that we don't yet have control over.
> > > >>
> > > >> We do have the option of defining a class for
> ROYALE_CLASS_INFO,
> > but
> > > then it will never minify. I like the fact that it can minify
> > without us
> > > having to use shortnames. It makes our debug code more
> readable and
> > > doesn't waste space in small apps. Adding a class definition
> for
> > > ROYALE_CLASS_INFO would further add overhead to small apps.
> > > >>
> > > >> My 2 cents,
> > > >> -Alex
> > > >>
> > > >> On 12/11/18, 2:06 PM, "Harbs" <harbs.lists@gmail.com
> <mailto:
> > > harbs.lists@gmail.com> <mailto:harbs.lists@gmail.com <mailto:
> > > harbs.lists@gmail.com>>> wrote:
> > > >>
> > > >> In fact, in looking through the framework code so far,
> the only
> > place
> > > I’ve found variable names not quoted (in JS compatible code)
> so far
> > was in
> > > CSSUtils where we have a colorMap. I’m pretty sure the
> colorMap will
> > not
> > > work after minification because the color names will not match…
> > > >>
> > > >>> On Dec 12, 2018, at 12:01 AM, Harbs <harbs.lists@gmail.com
> > <mailto:
> > > harbs.lists@gmail.com>> wrote:
> > > >>>
> > > >>> Hi Carlos,
> > > >>>
> > > >>> We’re only discussing dynamic objects. How many of those
> do you
> > have
> > > in your applications? I doubt there’s much difference in
> performance
> > due to
> > > minification of dynamic objects.
> > > >>>
> > > >>> In *all* our framework code we have dynamic object
> instantiation
> > in
> > > 435 places including TLF, Spark and MX classes. Without those
> > packages, I’m
> > > estimating it’s a small fraction of that and probably most of
> the
> > dynamic
> > > objects are hash maps where they don’t benefit from
> minification
> > anyway.
> > > >>>
> > > >>> The vast majority of the cases where you’re using dynamic
> > objects in
> > > production code you don’t want the names minified either (i.e.
> API
> > calls
> > > and uses of JSON).
> > > >>>
> > > >>> I think that most of this discussion is more theoretical
> than
> > > practical considerations.
> > > >>>
> > > >>> My $0.02,
> > > >>> Harbs
> > > >>>
> > > >>>> On Dec 11, 2018, at 11:26 PM, Carlos Rovira <
> > carlosrovira@apache.org
> > > <ma...@apache.org>> wrote:
> > > >>>>
> > > >>>> Hi,
> > > >>>>
> > > >>>> I'm still not using modules. I left that for now until we
> > complete the
> > > >>>> first phase in our project, but will be using (hopefully)
> around
> > > February.
> > > >>>>
> > > >>>> So right now we're only using minification, that seems
> not only
> > to
> > > reduce
> > > >>>> the size of the build, but release mode performs faster,
> and I
> > think
> > > is
> > > >>>> due, in part, to minify.
> > > >>>>
> > > >>>> So, IMHO, as a user, I don't like A). Can't think of a
> solution,
> > > since is
> > > >>>> not my zone of expertise, and sure you guys found a good
> > solution
> > > after
> > > >>>> all. Just want to say that as a user, is importante both
> > things: have
> > > >>>> modules (and hope we could link as well with routing like
> > people do in
> > > >>>> other current techs like React and Angular to get a
> powerful
> > solution
> > > for
> > > >>>> SPAs) and have minification, since IMO, the resultant
> js-release
> > > build has
> > > >>>> many, many advantages, not only in performance and size
> but as
> > well in
> > > >>>> obfuscation, and for me is like our "binary output code".
> > > >>>>
> > > >>>> Sorry to not be able to give any suggestion, but maybe as
> well
> > an
> > > opinion
> > > >>>> of use is as well valuable.
> > > >>>>
> > > >>>> just my 2
> > > >>>>
> > > >>>>
> > > >>>> El mar., 11 dic. 2018 a las 21:24, Alex Harui
> > > (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
> > > >>>> escribió:
> > > >>>>
> > > >>>>> Thinking about it more, -js-dynamic-access probably won't
> > help. We
> > > don't
> > > >>>>> want to compile our SWCs with that option on and thus
> turn off
> > > minification
> > > >>>>> of these field names always if we can help it.
> > > >>>>>
> > > >>>>> Even a directive per occurrence won't help either.
> Whether a
> > field
> > > name
> > > >>>>> is renamed is still dependent on what other code is in
> the
> > > compilation.
> > > >>>>>
> > > >>>>> The problem is better described as trying to find a way
> to
> > control
> > > what
> > > >>>>> field names get renamed in more than one compilation,
> given
> > that
> > > there is
> > > >>>>> pre-transpiled code that allows renaming. When building
> > modules, we
> > > >>>>> already require using Closure Compiler options that
> output the
> > > renaming
> > > >>>>> maps of the main app so that UIBase is given the same
> short
> > name in
> > > all
> > > >>>>> minifications. But there is no way to dictate that for
> field
> > names
> > > as far
> > > >>>>> as I can tell.
> > > >>>>>
> > > >>>>> -Alex
> > > >>>>>
> > > >>>>> On 12/11/18, 11:32 AM, "Harbs" <harbs.lists@gmail.com
> <mailto:
> > > harbs.lists@gmail.com>> wrote:
> > > >>>>>
> > > >>>>> I vote for A.
> > > >>>>>
> > > >>>>> We can also do B which would require manually changing
> all
> > access to
> > > >>>>> brackets and quote all names in object literals.
> > > >>>>>
> > > >>>>> I might be nice to add some comment decorations to
> > enable/disable
> > > >>>>> -js-dynamic-access on a case-by-case basis, but I think
> it’s
> > > reasonable to
> > > >>>>> have a global on/off requirement. I’m already doing this
> for a
> > > library I
> > > >>>>> wrote which has a lot of dynamic data structures which
> does not
> > > survive
> > > >>>>> minification and the results are fine.
> > > >>>>>
> > > >>>>> My $0.02,
> > > >>>>> Harbs
> > > >>>>>
> > > >>>>>> On Dec 11, 2018, at 8:47 PM, Alex Harui
> > <aharui@adobe.com.INVALID
> > > <ma...@adobe.com.INVALID>>
> > > >>>>> wrote:
> > > >>>>>>
> > > >>>>>> IMO, some folks will want to rely on minification of
> object
> > field
> > > >>>>> names so save space. I think -js-dynamic-access blocks
> > minification.
> > > >>>>>>
> > > >>>>>> So, to try to pose the problem another way, you can
> rely on
> > > >>>>> minification object field names if you are building a
> > single-js-file
> > > app,
> > > >>>>> but as soon as you start using modules, things may
> break. So
> > what
> > > should
> > > >>>>> we tell folks?
> > > >>>>>>
> > > >>>>>> A) if you use modules you must turn off minification in
> > objects with
> > > >>>>> -js-dynamic-access
> > > >>>>>> B) here are some ways to hack your code so you can
> still rely
> > on
> > > >>>>> minification
> > > >>>>>> C) something else?
> > > >>>>>>
> > > >>>>>> We can manually rename fields in ROYALE_CLASS_INFO and
> other
> > > >>>>> structures to make our code less readable in debug mode
> but
> > save
> > > space in
> > > >>>>> release mode, but that does not solve the general case
> problem.
> > > Folks may
> > > >>>>> have other objects in their apps and modules that work
> until
> > you add
> > > some
> > > >>>>> code to one of the projects that changes which object
> fields
> > get
> > > renamed.
> > > >>>>>>
> > > >>>>>> -Alex
> > > >>>>>>
> > > >>>>>> On 12/11/18, 9:31 AM, "Harbs" <harbs.lists@gmail.com
> <mailto:
> > > harbs.lists@gmail.com>> wrote:
> > > >>>>>>
> > > >>>>>> I’m not following why this is the same point.
> > > >>>>>>
> > > >>>>>> I’m using -js-dynamic-access-unknown-members=true to
> handle
> > this
> > > >>>>> kind of problem. It works flawlessly…
> > > >>>>>>
> > > >>>>>> I’d personally argue that true should be the default,
> but
> > whether
> > > >>>>> the default is true or not, we do have an option to deal
> with
> > these
> > > kinds
> > > >>>>> of data structures.
> > > >>>>>>
> > > >>>>>>> On Dec 11, 2018, at 6:39 PM, Alex Harui
> > <aharui@adobe.com.INVALID
> > > <ma...@adobe.com.INVALID>>
> > > >>>>> wrote:
> > > >>>>>>>
> > > >>>>>>> Yes, we can use our own short names in code we
> generate, but
> > that's
> > > >>>>> not really the point.
> > > >>>>>>>
> > > >>>>>>> The point is that any plain object field can be renamed
> > based on
> > > >>>>> other code in the compile. So if you just have:
> > > >>>>>>>
> > > >>>>>>> Var obj:Object = { harbs: 1};
> > > >>>>>>> Public static function foo()
> > > >>>>>>> {
> > > >>>>>>> Trace(obj.harbs);
> > > >>>>>>> }
> > > >>>>>>>
> > > >>>>>>> Use of foo() in one compile may result in harbs being
> > renamed, and
> > > >>>>> another wouldn't. And that poses a problem when data
> > structures are
> > > shared
> > > >>>>> between compiled outputs.
> > > >>>>>>>
> > > >>>>>>> This is a natural way to write AS, but the JS results
> when
> > minified
> > > >>>>> and shared between app and modules can fail. So what
> > restrictions
> > > should
> > > >>>>> we place if any on how folks use plain objects?
> > > >>>>>>>
> > > >>>>>>> HTH,
> > > >>>>>>> -Alex
> > > >>>>>>>
> > > >>>>>>> On 12/11/18, 7:36 AM, "Harbs" <harbs.lists@gmail.com
> > <mailto:
> > > harbs.lists@gmail.com>> wrote:
> > > >>>>>>>
> > > >>>>>>> I was about to make the same suggestion. We can use
> “I” for
> > > >>>>> interfaces, “c” for class, “k” for kind, “n” for names.
> etc.
> > > >>>>>>>
> > > >>>>>>>> On Dec 11, 2018, at 2:52 PM, Frost, Andrew
> > > <Andrew.Frost@Harman.com <ma...@Harman.com>>
> > > >>>>> wrote:
> > > >>>>>>>>
> > > >>>>>>>> Hi
> > > >>>>>>>>
> > > >>>>>>>> Not sure that I fully understand this but would a
> valid
> > compromise
> > > >>>>> be something where the field name isn't renamed at all
> > > automatically, but
> > > >>>>> we just change it in the JS generation code to be "i"
> rather
> > than
> > > >>>>> "interfaces", and update the Language is/as functions to
> work
> > with
> > > this
> > > >>>>> property name? Not sure whether it would work and I
> don't know
> > > whether the
> > > >>>>> Reflection stuff would then need to change too, but if
> this is
> > all
> > > in the
> > > >>>>> generated outputs and/or the framework's own code then it
> > shouldn't
> > > be
> > > >>>>> something that the end user would bother about..
> > > >>>>>>>>
> > > >>>>>>>> thanks
> > > >>>>>>>>
> > > >>>>>>>> Andrew
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> -----Original Message-----
> > > >>>>>>>> From: Alex Harui [mailto:aharui@adobe.com.INVALID
> <mailto:
> > > aharui@adobe.com.INVALID>]
> > > >>>>>>>> Sent: 11 December 2018 08:32
> > > >>>>>>>> To: dev@royale.apache.org <mailto:
> dev@royale.apache.org>
> > > >>>>>>>> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming,
> modules,
> > Objects
> > > >>>>>>>>
> > > >>>>>>>> I spent some time today trying to get Tour De Flex to
> run in
> > > >>>>> production mode with the main app and modules being
> separately
> > > minified.
> > > >>>>>>>>
> > > >>>>>>>> I've fixed a few things here and there, but an
> interesting
> > issue I
> > > >>>>> ran into has to do with the plain object we use in
> > ROYALE_CLASS_INFO
> > > (and
> > > >>>>> will apply to other objects).
> > > >>>>>>>>
> > > >>>>>>>> The ROYALE_CLASS_INFO is generated on each class and
> has a
> > "names"
> > > >>>>> property and an optional "interfaces" property. An
> example is:
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>
> > >
> >
> org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO
> > > >>>>> = { names: [{ name: 'PanelModel', qName:
> > > >>>>> 'org.apache.royale.html.beads.models.PanelModel', kind:
> > 'class' }],
> > > >>>>> interfaces: [org.apache.royale.core.IBead,
> > > >>>>> org.apache.royale.core.IPanelModel] };
> > > >>>>>>>>
> > > >>>>>>>> Because the field names are not quoted, then in most
> > output, the
> > > >>>>> field name "interfaces" is renamed and all code
> referencing
> > this
> > > field is
> > > >>>>> renamed as well. This is good because it means that you
> don't
> > have
> > > to
> > > >>>>> download the word "interfaces" once per-class. Instead
> of 10
> > > characters, it
> > > >>>>> is usually one or two. 100 classes saves you about 900
> bytes.
> > > >>>>>>>>
> > > >>>>>>>> However, it turns out that in Tour De Flex, the main
> app
> > uses
> > > >>>>> Reflection and Reflection uses a quoted 'interfaces'
> string and
> > > thus, the
> > > >>>>> field name 'interfaces' in ROYALE_CLASS_INFO isn't
> renamed,
> > but in
> > > most
> > > >>>>> modules "interfaces" is renamed since no other code in
> the
> > module
> > > has a
> > > >>>>> quoted string for 'interfaces'. But that means that
> when a
> > module
> > > loads,
> > > >>>>> the Language.is/as <
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flanguage.is%2Fas&data=02%7C01%7Caharui%40adobe.com%7C00fc453c2c24467304ff08d6613da337%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636803314718255897&sdata=qEiy1zaCVn7jvmDUq3QGPBUl1NacAAzryKBNrQFIXdk%3D&reserved=0
> >
> > won't work since classes
> > > in the main app are using
> > > >>>>> "interfaces" but the classes in the module are using some
> > short name.
> > > >>>>>>>>
> > > >>>>>>>> One solution is to always quote that field in the
> compiler
> > output
> > > >>>>> and Language is/as so it doesn't get renamed, but that
> means
> > that
> > > field
> > > >>>>> will never get renamed and you lose saving those bytes.
> > > >>>>>>>>
> > > >>>>>>>> Another is let folks figure out their own
> workarounds, by
> > adding
> > > >>>>> some code that will prevent the renaming in the modules.
> > > >>>>>>>>
> > > >>>>>>>> Other ideas are welcome. I'm done for tonight.
> > > >>>>>>>>
> > > >>>>>>>> Thoughts?
> > > >>>>>>>> -Alex
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>>> --
> > > >>>> Carlos Rovira
> > > >>>>
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C00fc453c2c24467304ff08d6613da337%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636803314718265897&sdata=sI0TqfMHCC%2BDLSMURhCyaU5Xbyv44TgTii3Hlur1xAg%3D&reserved=0
> > > <
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C00fc453c2c24467304ff08d6613da337%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636803314718265897&sdata=sI0TqfMHCC%2BDLSMURhCyaU5Xbyv44TgTii3Hlur1xAg%3D&reserved=0
> > > ><
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C00fc453c2c24467304ff08d6613da337%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636803314718265897&sdata=sI0TqfMHCC%2BDLSMURhCyaU5Xbyv44TgTii3Hlur1xAg%3D&reserved=0
> > > <
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C00fc453c2c24467304ff08d6613da337%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636803314718265897&sdata=sI0TqfMHCC%2BDLSMURhCyaU5Xbyv44TgTii3Hlur1xAg%3D&reserved=0
> > > >>
> > >
> > >
> >
> > --
> >
> > <
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7Caharui%40adobe.com%7C00fc453c2c24467304ff08d6613da337%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636803314719006415&sdata=OoGGMKhwOpCC4JRArhVhruSbvTPrTBdSNdMWTORn10w%3D&reserved=0
> > >
> >
> > Carlos Rovira
> >
> > Presidente Ejecutivo
> >
> > M: +34 607 22 60 05
> >
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7Caharui%40adobe.com%7C00fc453c2c24467304ff08d6613da337%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636803314719006415&sdata=OoGGMKhwOpCC4JRArhVhruSbvTPrTBdSNdMWTORn10w%3D&reserved=0
> >
> >
> > Conócenos en 1 minuto! <
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favant2.es%2F%23video&data=02%7C01%7Caharui%40adobe.com%7C00fc453c2c24467304ff08d6613da337%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636803314719006415&sdata=g80Hp0EMXrttHsw93e1F5HIisArzf%2BXhIQYqa0DKxnY%3D&reserved=0
> > >
> >
> >
> > AVISO LEGAL: La información contenida en este correo
> electrónico, y en
> > su
> > caso en los documentos adjuntos, es información privilegiada
> para uso
> > exclusivo de la persona y/o personas a las que va dirigido. No
> está
> > permitido el acceso a este mensaje a cualquier otra persona
> distinta a
> > los
> > indicados. Si Usted no es uno de los destinatarios, cualquier
> > duplicación,
> > reproducción, distribución, así como cualquier uso de la
> información
> > contenida en él o cualquiera otra acción u omisión tomada en
> relación
> > con
> > el mismo, está prohibida y puede ser ilegal. En dicho caso, por
> favor,
> > notifíquelo al remitente y proceda a la eliminación de este
> correo
> > electrónico, así como de sus adjuntos si los hubiere. En
> cumplimiento
> > de la
> > legislación española vigente en materia de protección de datos de
> > carácter
> > personal y del RGPD 679/2016 le informamos que sus datos están
> siendo
> > objeto de tratamiento por parte de CODEOSCOPIC S.A. con
> CIFA85677342,
> > con
> > la finalidad del mantenimiento y gestión de relaciones
> comerciales y
> > administrativas. La base jurídica del tratamiento es el interés
> > legítimo de
> > la empresa. No se prevén cesiones de sus datos, salvo que exista
> una
> > obligación legal. Para ejercitar sus derechos puede dirigirse a
> > CODEOSCOPIC
> > S.A., domiciliada enPaseo de la Habana, 9-11, 28036 de Madrid
> > (MADRID), o
> > bien por email adpd@codeoscopic.com, con el fin de ejercer sus
> > derechos de
> > acceso, rectificación, supresión (derecho al olvido), limitación
> de
> > tratamiento, portabilidad de los datos, oposición, y a no ser
> objeto de
> > decisiones automatizadas, indicando como Asunto: “Derechos Ley
> > Protección
> > de Datos”, y adjuntando fotocopia de su DNI. Delegado de
> protección de
> > datos:dpd@codeoscopic.com
> >
> >
> >
>
> --
>
> <
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7Caharui%40adobe.com%7C00fc453c2c24467304ff08d6613da337%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636803314719006415&sdata=OoGGMKhwOpCC4JRArhVhruSbvTPrTBdSNdMWTORn10w%3D&reserved=0
> >
>
> Carlos Rovira
>
> Presidente Ejecutivo
>
> M: +34 607 22 60 05
>
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7Caharui%40adobe.com%7C00fc453c2c24467304ff08d6613da337%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636803314719006415&sdata=OoGGMKhwOpCC4JRArhVhruSbvTPrTBdSNdMWTORn10w%3D&reserved=0
>
>
> Conócenos en 1 minuto! <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favant2.es%2F%23video&data=02%7C01%7Caharui%40adobe.com%7C00fc453c2c24467304ff08d6613da337%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636803314719006415&sdata=g80Hp0EMXrttHsw93e1F5HIisArzf%2BXhIQYqa0DKxnY%3D&reserved=0
> >
>
>
> AVISO LEGAL: La información contenida en este correo electrónico, y en
> su
> caso en los documentos adjuntos, es información privilegiada para uso
> exclusivo de la persona y/o personas a las que va dirigido. No está
> permitido el acceso a este mensaje a cualquier otra persona distinta a
> los
> indicados. Si Usted no es uno de los destinatarios, cualquier
> duplicación,
> reproducción, distribución, así como cualquier uso de la información
> contenida en él o cualquiera otra acción u omisión tomada en relación
> con
> el mismo, está prohibida y puede ser ilegal. En dicho caso, por favor,
> notifíquelo al remitente y proceda a la eliminación de este correo
> electrónico, así como de sus adjuntos si los hubiere. En cumplimiento
> de la
> legislación española vigente en materia de protección de datos de
> carácter
> personal y del RGPD 679/2016 le informamos que sus datos están siendo
> objeto de tratamiento por parte de CODEOSCOPIC S.A. con CIFA85677342,
> con
> la finalidad del mantenimiento y gestión de relaciones comerciales y
> administrativas. La base jurídica del tratamiento es el interés
> legítimo de
> la empresa. No se prevén cesiones de sus datos, salvo que exista una
> obligación legal. Para ejercitar sus derechos puede dirigirse a
> CODEOSCOPIC
> S.A., domiciliada enPaseo de la Habana, 9-11, 28036 de Madrid
> (MADRID), o
> bien por email adpd@codeoscopic.com, con el fin de ejercer sus
> derechos de
> acceso, rectificación, supresión (derecho al olvido), limitación de
> tratamiento, portabilidad de los datos, oposición, y a no ser objeto de
> decisiones automatizadas, indicando como Asunto: “Derechos Ley
> Protección
> de Datos”, y adjuntando fotocopia de su DNI. Delegado de protección de
> datos:dpd@codeoscopic.com
>
>
>
Re: ROYALE_CLASS_INFO, renaming, modules, Objects
Posted by Greg Dove <gr...@gmail.com>.
Alex, the compiler change you made recently for some things to 'prevent
renaming' for modules may require changes in related support classes in the
framework. I had to make a change in ClassAliasBead to have it continue to
work in release mode. I did that to get it working again because we are
using it and I could verify, but I see now that JSONReviver will likely
need the same change. I'm not using that so not in a position to verify it
and others. You probably know all the locations well in the framework that
relate to the compiler changes and I'm guessing you are in a better
position to test them (because I only used the alias stuff so far)... just
letting you know in case they may need the same treatment...
On Thu, Dec 13, 2018 at 2:11 PM Alex Harui <ah...@adobe.com.invalid> wrote:
> Closure Compiler will rename (to a short name) any object and property on
> any object that isn't marked as "don’t rename" via several techniques:
>
> 1) Externs
> 2) @export
> 3) bracket syntax (i.e. obj["dontRenameThisProperty"])
> 4) having a getter and/or setter of the same name elsewhere in the
> compilation
>
> By default, all Royale public and protected properties are marked as
> @export so they will never be renamed. That's what you want when
> deserializing network data or when folks might be using bracket syntax to
> access properties.
>
> It "should be" ok for us and others to use plain objects than can be
> minified/renamed if needed. The key is being able to control what gets
> minified. I think #4 gives a way to control it.
>
> HTH,
> -Alex
>
> On 12/12/18, 9:10 AM, "Carlos Rovira" <ca...@codeoscopic.com>
> wrote:
>
> Hi Alex,
>
> what do you mean with "prevent renaming"? there's some process that
> implies a renaming? and renaming of what? the nested properties?
>
> thanks
>
>
>
> El mié., 12 dic. 2018 a las 17:21, Alex Harui
> (<ah...@adobe.com.invalid>)
> escribió:
>
> > Using a plain object allows renaming. Using a class definition
> prevents
> > renaming.
> >
> > Using shortnames in plain objects prevents renaming but is, IMO, a
> bad
> > practice. Why make our code harder to read? It isn't just in the
> data
> > structure, but in the code that reads it.
> >
> > -Alex
> >
> > On 12/12/18, 2:34 AM, "Carlos Rovira" <carlos.rovira@codeoscopic.com
> >
> > wrote:
> >
> > Harb,
> >
> > That seems ok, but moreover...why don't we have a class
> definition
> > instead
> > a plain object, somethings like RoyaleClassInfo.as?
> > Since Royale tries to enforce typing, I think using a plain
> object for
> > royale class info, doesn't seems the most proper way to me
> >
> > thanks
> >
> >
> >
> > El mié., 12 dic. 2018 a las 11:23, Harbs (<harbs.lists@gmail.com
> >)
> > escribió:
> >
> > > Right, but I thought we already suggested single character
> names for
> > the
> > > ROYALE_CLASS_INFO object.
> > >
> > > To take one example:
> > >
> >
> org.apache.royale.html.supportClasses.Viewport.prototype.ROYALE_CLASS_INFO
> > > = { names: [{ name: 'Viewport', qName:
> > > 'org.apache.royale.html.supportClasses.Viewport', kind:
> 'class' }],
> > > interfaces: [org.apache.royale.core.IBead,
> > > org.apache.royale.core.IViewport] };
> > >
> > > That would become:
> > >
> >
> org.apache.royale.html.supportClasses.Viewport.prototype.ROYALE_CLASS_INFO
> > > = { n: [{ n: 'Viewport', q:
> > > 'org.apache.royale.html.supportClasses.Viewport', k: 'class'
> }], i:
> > > [org.apache.royale.core.IBead,
> org.apache.royale.core.IViewport] };
> > >
> > > I’m pretty sure that’s enough to prevent renaming (because the
> > closure
> > > compiler does not rename single character variable names). If
> I’m
> > wrong, we
> > > could always output something like this:
> > >
> > >
> >
> org.apache.royale.html.supportClasses.Viewport.prototype.ROYALE_CLASS_INFO
> > > = { 'n': [{ 'n': 'Viewport', 'q':
> > > 'org.apache.royale.html.supportClasses.Viewport', 'k': 'class'
> }],
> > 'i':
> > > [org.apache.royale.core.IBead,
> org.apache.royale.core.IViewport] };
> > >
> > > Am I missing something?
> > > Harbs
> > >
> > > > On Dec 12, 2018, at 12:32 AM, Alex Harui
> <aharui@adobe.com.INVALID
> > >
> > > wrote:
> > > >
> > > > ROYALE_CLASS_INFO is a dynamic object. There is no class
> > definition for
> > > it, which means that its field names can be renamed.
> > > >
> > > > The whole point of modules is to load classes that aren't in
> the
> > main
> > > app so that the main app loads faster. So, if you have
> > > >
> > > > MainApp.mxml
> > > > <mx:Application>
> > > > <mx:ModuleLoader url="MyModule" />
> > > > </mx:Application>
> > > >
> > > > MyModule.mxml
> > > > <mx:Module>
> > > > </mx:Module>
> > > >
> > > > The Language.is <
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flanguage.is%2F&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=qSasD0ckW6c6zl6hj9mXyBlFHUaTHFA6Usz6YZi0bGs%3D&reserved=0
> >
> > function linked into Main app
> > > might be checking for ROYALE_CLASS_INFO.interfaces and
> Application
> > class
> > > will have a ROYALE_CLASS_INFO.interfaces property. But Module
> might
> > have
> > > ROYALE_CLASS_INFO.i instead of interfaces. And thus
> Language.is <
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flanguage.is%2F&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=qSasD0ckW6c6zl6hj9mXyBlFHUaTHFA6Usz6YZi0bGs%3D&reserved=0
> >
> > will not work on classes in the module. It depends
> > > on what other code is in the main app. It appears that use of
> > > Reflection.SWC's TypeDefinition in the main app tells the
> minifier
> > to not
> > > minify the "interfaces" property. Which means that any code
> an app
> > > developer might add to the app could change the minification of
> > > ROYALE_CLASS_INFO, or any other dynamic object.
> > > >
> > > > I'm trying to figure out why the minifier thinks the use of
> > "interfaces"
> > > in TypeDefinition matters but other attempts I've tried to
> force the
> > > minifier to not rename "interfaces" in the module have not
> worked.
> > > >
> > > > HTH,
> > > > -Alex
> > > >
> > > > On 12/11/18, 2:19 PM, "Harbs" <harbs.lists@gmail.com
> <mailto:
> > > harbs.lists@gmail.com>> wrote:
> > > >
> > > > I’m still not getting the connection to ROYALE_CLASS_INFO.
> > > >
> > > > Can you explain to me in pseudo-code the problem with
> that? Why
> > does
> > > a dynamic object have ROYALE_CLASS_INFO at all?
> > > >
> > > >> On Dec 12, 2018, at 12:16 AM, Alex Harui
> <aharui@adobe.com.INVALID
> > >
> > > wrote:
> > > >>
> > > >> I'm not sure why you think it is theoretical. For sure, in
> TDF,
> > the
> > > module is not loading because ROYALE_CLASS_INFO is minified
> > differently in
> > > the main app than the module. Any dynamic objects shared across
> > > compilations are at risk of being renamed differently. I'm
> chasing
> > down a
> > > way to control it.
> > > >>
> > > >> We do have control over the names of classes and properties
> to
> > > guarantee they are the same in the app and module. It is just
> these
> > > dynamic object keys that we don't yet have control over.
> > > >>
> > > >> We do have the option of defining a class for
> ROYALE_CLASS_INFO,
> > but
> > > then it will never minify. I like the fact that it can minify
> > without us
> > > having to use shortnames. It makes our debug code more
> readable and
> > > doesn't waste space in small apps. Adding a class definition
> for
> > > ROYALE_CLASS_INFO would further add overhead to small apps.
> > > >>
> > > >> My 2 cents,
> > > >> -Alex
> > > >>
> > > >> On 12/11/18, 2:06 PM, "Harbs" <harbs.lists@gmail.com
> <mailto:
> > > harbs.lists@gmail.com> <mailto:harbs.lists@gmail.com <mailto:
> > > harbs.lists@gmail.com>>> wrote:
> > > >>
> > > >> In fact, in looking through the framework code so far,
> the only
> > place
> > > I’ve found variable names not quoted (in JS compatible code)
> so far
> > was in
> > > CSSUtils where we have a colorMap. I’m pretty sure the
> colorMap will
> > not
> > > work after minification because the color names will not match…
> > > >>
> > > >>> On Dec 12, 2018, at 12:01 AM, Harbs <harbs.lists@gmail.com
> > <mailto:
> > > harbs.lists@gmail.com>> wrote:
> > > >>>
> > > >>> Hi Carlos,
> > > >>>
> > > >>> We’re only discussing dynamic objects. How many of those
> do you
> > have
> > > in your applications? I doubt there’s much difference in
> performance
> > due to
> > > minification of dynamic objects.
> > > >>>
> > > >>> In *all* our framework code we have dynamic object
> instantiation
> > in
> > > 435 places including TLF, Spark and MX classes. Without those
> > packages, I’m
> > > estimating it’s a small fraction of that and probably most of
> the
> > dynamic
> > > objects are hash maps where they don’t benefit from
> minification
> > anyway.
> > > >>>
> > > >>> The vast majority of the cases where you’re using dynamic
> > objects in
> > > production code you don’t want the names minified either (i.e.
> API
> > calls
> > > and uses of JSON).
> > > >>>
> > > >>> I think that most of this discussion is more theoretical
> than
> > > practical considerations.
> > > >>>
> > > >>> My $0.02,
> > > >>> Harbs
> > > >>>
> > > >>>> On Dec 11, 2018, at 11:26 PM, Carlos Rovira <
> > carlosrovira@apache.org
> > > <ma...@apache.org>> wrote:
> > > >>>>
> > > >>>> Hi,
> > > >>>>
> > > >>>> I'm still not using modules. I left that for now until we
> > complete the
> > > >>>> first phase in our project, but will be using (hopefully)
> around
> > > February.
> > > >>>>
> > > >>>> So right now we're only using minification, that seems
> not only
> > to
> > > reduce
> > > >>>> the size of the build, but release mode performs faster,
> and I
> > think
> > > is
> > > >>>> due, in part, to minify.
> > > >>>>
> > > >>>> So, IMHO, as a user, I don't like A). Can't think of a
> solution,
> > > since is
> > > >>>> not my zone of expertise, and sure you guys found a good
> > solution
> > > after
> > > >>>> all. Just want to say that as a user, is importante both
> > things: have
> > > >>>> modules (and hope we could link as well with routing like
> > people do in
> > > >>>> other current techs like React and Angular to get a
> powerful
> > solution
> > > for
> > > >>>> SPAs) and have minification, since IMO, the resultant
> js-release
> > > build has
> > > >>>> many, many advantages, not only in performance and size
> but as
> > well in
> > > >>>> obfuscation, and for me is like our "binary output code".
> > > >>>>
> > > >>>> Sorry to not be able to give any suggestion, but maybe as
> well
> > an
> > > opinion
> > > >>>> of use is as well valuable.
> > > >>>>
> > > >>>> just my 2
> > > >>>>
> > > >>>>
> > > >>>> El mar., 11 dic. 2018 a las 21:24, Alex Harui
> > > (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
> > > >>>> escribió:
> > > >>>>
> > > >>>>> Thinking about it more, -js-dynamic-access probably won't
> > help. We
> > > don't
> > > >>>>> want to compile our SWCs with that option on and thus
> turn off
> > > minification
> > > >>>>> of these field names always if we can help it.
> > > >>>>>
> > > >>>>> Even a directive per occurrence won't help either.
> Whether a
> > field
> > > name
> > > >>>>> is renamed is still dependent on what other code is in
> the
> > > compilation.
> > > >>>>>
> > > >>>>> The problem is better described as trying to find a way
> to
> > control
> > > what
> > > >>>>> field names get renamed in more than one compilation,
> given
> > that
> > > there is
> > > >>>>> pre-transpiled code that allows renaming. When building
> > modules, we
> > > >>>>> already require using Closure Compiler options that
> output the
> > > renaming
> > > >>>>> maps of the main app so that UIBase is given the same
> short
> > name in
> > > all
> > > >>>>> minifications. But there is no way to dictate that for
> field
> > names
> > > as far
> > > >>>>> as I can tell.
> > > >>>>>
> > > >>>>> -Alex
> > > >>>>>
> > > >>>>> On 12/11/18, 11:32 AM, "Harbs" <harbs.lists@gmail.com
> <mailto:
> > > harbs.lists@gmail.com>> wrote:
> > > >>>>>
> > > >>>>> I vote for A.
> > > >>>>>
> > > >>>>> We can also do B which would require manually changing
> all
> > access to
> > > >>>>> brackets and quote all names in object literals.
> > > >>>>>
> > > >>>>> I might be nice to add some comment decorations to
> > enable/disable
> > > >>>>> -js-dynamic-access on a case-by-case basis, but I think
> it’s
> > > reasonable to
> > > >>>>> have a global on/off requirement. I’m already doing this
> for a
> > > library I
> > > >>>>> wrote which has a lot of dynamic data structures which
> does not
> > > survive
> > > >>>>> minification and the results are fine.
> > > >>>>>
> > > >>>>> My $0.02,
> > > >>>>> Harbs
> > > >>>>>
> > > >>>>>> On Dec 11, 2018, at 8:47 PM, Alex Harui
> > <aharui@adobe.com.INVALID
> > > <ma...@adobe.com.INVALID>>
> > > >>>>> wrote:
> > > >>>>>>
> > > >>>>>> IMO, some folks will want to rely on minification of
> object
> > field
> > > >>>>> names so save space. I think -js-dynamic-access blocks
> > minification.
> > > >>>>>>
> > > >>>>>> So, to try to pose the problem another way, you can
> rely on
> > > >>>>> minification object field names if you are building a
> > single-js-file
> > > app,
> > > >>>>> but as soon as you start using modules, things may
> break. So
> > what
> > > should
> > > >>>>> we tell folks?
> > > >>>>>>
> > > >>>>>> A) if you use modules you must turn off minification in
> > objects with
> > > >>>>> -js-dynamic-access
> > > >>>>>> B) here are some ways to hack your code so you can
> still rely
> > on
> > > >>>>> minification
> > > >>>>>> C) something else?
> > > >>>>>>
> > > >>>>>> We can manually rename fields in ROYALE_CLASS_INFO and
> other
> > > >>>>> structures to make our code less readable in debug mode
> but
> > save
> > > space in
> > > >>>>> release mode, but that does not solve the general case
> problem.
> > > Folks may
> > > >>>>> have other objects in their apps and modules that work
> until
> > you add
> > > some
> > > >>>>> code to one of the projects that changes which object
> fields
> > get
> > > renamed.
> > > >>>>>>
> > > >>>>>> -Alex
> > > >>>>>>
> > > >>>>>> On 12/11/18, 9:31 AM, "Harbs" <harbs.lists@gmail.com
> <mailto:
> > > harbs.lists@gmail.com>> wrote:
> > > >>>>>>
> > > >>>>>> I’m not following why this is the same point.
> > > >>>>>>
> > > >>>>>> I’m using -js-dynamic-access-unknown-members=true to
> handle
> > this
> > > >>>>> kind of problem. It works flawlessly…
> > > >>>>>>
> > > >>>>>> I’d personally argue that true should be the default,
> but
> > whether
> > > >>>>> the default is true or not, we do have an option to deal
> with
> > these
> > > kinds
> > > >>>>> of data structures.
> > > >>>>>>
> > > >>>>>>> On Dec 11, 2018, at 6:39 PM, Alex Harui
> > <aharui@adobe.com.INVALID
> > > <ma...@adobe.com.INVALID>>
> > > >>>>> wrote:
> > > >>>>>>>
> > > >>>>>>> Yes, we can use our own short names in code we
> generate, but
> > that's
> > > >>>>> not really the point.
> > > >>>>>>>
> > > >>>>>>> The point is that any plain object field can be renamed
> > based on
> > > >>>>> other code in the compile. So if you just have:
> > > >>>>>>>
> > > >>>>>>> Var obj:Object = { harbs: 1};
> > > >>>>>>> Public static function foo()
> > > >>>>>>> {
> > > >>>>>>> Trace(obj.harbs);
> > > >>>>>>> }
> > > >>>>>>>
> > > >>>>>>> Use of foo() in one compile may result in harbs being
> > renamed, and
> > > >>>>> another wouldn't. And that poses a problem when data
> > structures are
> > > shared
> > > >>>>> between compiled outputs.
> > > >>>>>>>
> > > >>>>>>> This is a natural way to write AS, but the JS results
> when
> > minified
> > > >>>>> and shared between app and modules can fail. So what
> > restrictions
> > > should
> > > >>>>> we place if any on how folks use plain objects?
> > > >>>>>>>
> > > >>>>>>> HTH,
> > > >>>>>>> -Alex
> > > >>>>>>>
> > > >>>>>>> On 12/11/18, 7:36 AM, "Harbs" <harbs.lists@gmail.com
> > <mailto:
> > > harbs.lists@gmail.com>> wrote:
> > > >>>>>>>
> > > >>>>>>> I was about to make the same suggestion. We can use
> “I” for
> > > >>>>> interfaces, “c” for class, “k” for kind, “n” for names.
> etc.
> > > >>>>>>>
> > > >>>>>>>> On Dec 11, 2018, at 2:52 PM, Frost, Andrew
> > > <Andrew.Frost@Harman.com <ma...@Harman.com>>
> > > >>>>> wrote:
> > > >>>>>>>>
> > > >>>>>>>> Hi
> > > >>>>>>>>
> > > >>>>>>>> Not sure that I fully understand this but would a
> valid
> > compromise
> > > >>>>> be something where the field name isn't renamed at all
> > > automatically, but
> > > >>>>> we just change it in the JS generation code to be "i"
> rather
> > than
> > > >>>>> "interfaces", and update the Language is/as functions to
> work
> > with
> > > this
> > > >>>>> property name? Not sure whether it would work and I
> don't know
> > > whether the
> > > >>>>> Reflection stuff would then need to change too, but if
> this is
> > all
> > > in the
> > > >>>>> generated outputs and/or the framework's own code then it
> > shouldn't
> > > be
> > > >>>>> something that the end user would bother about..
> > > >>>>>>>>
> > > >>>>>>>> thanks
> > > >>>>>>>>
> > > >>>>>>>> Andrew
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> -----Original Message-----
> > > >>>>>>>> From: Alex Harui [mailto:aharui@adobe.com.INVALID
> <mailto:
> > > aharui@adobe.com.INVALID>]
> > > >>>>>>>> Sent: 11 December 2018 08:32
> > > >>>>>>>> To: dev@royale.apache.org <mailto:
> dev@royale.apache.org>
> > > >>>>>>>> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming,
> modules,
> > Objects
> > > >>>>>>>>
> > > >>>>>>>> I spent some time today trying to get Tour De Flex to
> run in
> > > >>>>> production mode with the main app and modules being
> separately
> > > minified.
> > > >>>>>>>>
> > > >>>>>>>> I've fixed a few things here and there, but an
> interesting
> > issue I
> > > >>>>> ran into has to do with the plain object we use in
> > ROYALE_CLASS_INFO
> > > (and
> > > >>>>> will apply to other objects).
> > > >>>>>>>>
> > > >>>>>>>> The ROYALE_CLASS_INFO is generated on each class and
> has a
> > "names"
> > > >>>>> property and an optional "interfaces" property. An
> example is:
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>
> > >
> >
> org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO
> > > >>>>> = { names: [{ name: 'PanelModel', qName:
> > > >>>>> 'org.apache.royale.html.beads.models.PanelModel', kind:
> > 'class' }],
> > > >>>>> interfaces: [org.apache.royale.core.IBead,
> > > >>>>> org.apache.royale.core.IPanelModel] };
> > > >>>>>>>>
> > > >>>>>>>> Because the field names are not quoted, then in most
> > output, the
> > > >>>>> field name "interfaces" is renamed and all code
> referencing
> > this
> > > field is
> > > >>>>> renamed as well. This is good because it means that you
> don't
> > have
> > > to
> > > >>>>> download the word "interfaces" once per-class. Instead
> of 10
> > > characters, it
> > > >>>>> is usually one or two. 100 classes saves you about 900
> bytes.
> > > >>>>>>>>
> > > >>>>>>>> However, it turns out that in Tour De Flex, the main
> app
> > uses
> > > >>>>> Reflection and Reflection uses a quoted 'interfaces'
> string and
> > > thus, the
> > > >>>>> field name 'interfaces' in ROYALE_CLASS_INFO isn't
> renamed,
> > but in
> > > most
> > > >>>>> modules "interfaces" is renamed since no other code in
> the
> > module
> > > has a
> > > >>>>> quoted string for 'interfaces'. But that means that
> when a
> > module
> > > loads,
> > > >>>>> the Language.is/as <
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flanguage.is%2Fas&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=yfr5w1B3EklIrmSVAoPV5T4ten96Qe%2F30TDHSHwS46w%3D&reserved=0
> >
> > won't work since classes
> > > in the main app are using
> > > >>>>> "interfaces" but the classes in the module are using some
> > short name.
> > > >>>>>>>>
> > > >>>>>>>> One solution is to always quote that field in the
> compiler
> > output
> > > >>>>> and Language is/as so it doesn't get renamed, but that
> means
> > that
> > > field
> > > >>>>> will never get renamed and you lose saving those bytes.
> > > >>>>>>>>
> > > >>>>>>>> Another is let folks figure out their own
> workarounds, by
> > adding
> > > >>>>> some code that will prevent the renaming in the modules.
> > > >>>>>>>>
> > > >>>>>>>> Other ideas are welcome. I'm done for tonight.
> > > >>>>>>>>
> > > >>>>>>>> Thoughts?
> > > >>>>>>>> -Alex
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>>> --
> > > >>>> Carlos Rovira
> > > >>>>
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=d73eQkK3bbLvNUeINo%2BIJrHjgy9IT7qrANobYwGnKS0%3D&reserved=0
> > > <
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=d73eQkK3bbLvNUeINo%2BIJrHjgy9IT7qrANobYwGnKS0%3D&reserved=0
> > > ><
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=d73eQkK3bbLvNUeINo%2BIJrHjgy9IT7qrANobYwGnKS0%3D&reserved=0
> > > <
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=d73eQkK3bbLvNUeINo%2BIJrHjgy9IT7qrANobYwGnKS0%3D&reserved=0
> > > >>
> > >
> > >
> >
> > --
> >
> > <
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=nJPHUMexoC7saf7a6MrfOQWYf%2FYdpFJTTes%2Bmgjc%2BNE%3D&reserved=0
> > >
> >
> > Carlos Rovira
> >
> > Presidente Ejecutivo
> >
> > M: +34 607 22 60 05
> >
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=nJPHUMexoC7saf7a6MrfOQWYf%2FYdpFJTTes%2Bmgjc%2BNE%3D&reserved=0
> >
> >
> > Conócenos en 1 minuto! <
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favant2.es%2F%23video&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520696571&sdata=%2BS%2B5eRSKU%2B3URIdfVfza0%2Fph3VjUjrk5hWRGTJXEhi8%3D&reserved=0
> > >
> >
> >
> > AVISO LEGAL: La información contenida en este correo
> electrónico, y en
> > su
> > caso en los documentos adjuntos, es información privilegiada
> para uso
> > exclusivo de la persona y/o personas a las que va dirigido. No
> está
> > permitido el acceso a este mensaje a cualquier otra persona
> distinta a
> > los
> > indicados. Si Usted no es uno de los destinatarios, cualquier
> > duplicación,
> > reproducción, distribución, así como cualquier uso de la
> información
> > contenida en él o cualquiera otra acción u omisión tomada en
> relación
> > con
> > el mismo, está prohibida y puede ser ilegal. En dicho caso, por
> favor,
> > notifíquelo al remitente y proceda a la eliminación de este
> correo
> > electrónico, así como de sus adjuntos si los hubiere. En
> cumplimiento
> > de la
> > legislación española vigente en materia de protección de datos de
> > carácter
> > personal y del RGPD 679/2016 le informamos que sus datos están
> siendo
> > objeto de tratamiento por parte de CODEOSCOPIC S.A. con
> CIFA85677342,
> > con
> > la finalidad del mantenimiento y gestión de relaciones
> comerciales y
> > administrativas. La base jurídica del tratamiento es el interés
> > legítimo de
> > la empresa. No se prevén cesiones de sus datos, salvo que exista
> una
> > obligación legal. Para ejercitar sus derechos puede dirigirse a
> > CODEOSCOPIC
> > S.A., domiciliada enPaseo de la Habana, 9-11, 28036 de Madrid
> > (MADRID), o
> > bien por email adpd@codeoscopic.com, con el fin de ejercer sus
> > derechos de
> > acceso, rectificación, supresión (derecho al olvido), limitación
> de
> > tratamiento, portabilidad de los datos, oposición, y a no ser
> objeto de
> > decisiones automatizadas, indicando como Asunto: “Derechos Ley
> > Protección
> > de Datos”, y adjuntando fotocopia de su DNI. Delegado de
> protección de
> > datos:dpd@codeoscopic.com
> >
> >
> >
>
> --
>
> <
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520696571&sdata=6PTVtYdOOp3s4eF0zwTq7uRo5xxpbvl1T3TZdUIY20g%3D&reserved=0
> >
>
> Carlos Rovira
>
> Presidente Ejecutivo
>
> M: +34 607 22 60 05
>
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520696571&sdata=6PTVtYdOOp3s4eF0zwTq7uRo5xxpbvl1T3TZdUIY20g%3D&reserved=0
>
>
> Conócenos en 1 minuto! <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favant2.es%2F%23video&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520696571&sdata=%2BS%2B5eRSKU%2B3URIdfVfza0%2Fph3VjUjrk5hWRGTJXEhi8%3D&reserved=0
> >
>
>
> AVISO LEGAL: La información contenida en este correo electrónico, y en
> su
> caso en los documentos adjuntos, es información privilegiada para uso
> exclusivo de la persona y/o personas a las que va dirigido. No está
> permitido el acceso a este mensaje a cualquier otra persona distinta a
> los
> indicados. Si Usted no es uno de los destinatarios, cualquier
> duplicación,
> reproducción, distribución, así como cualquier uso de la información
> contenida en él o cualquiera otra acción u omisión tomada en relación
> con
> el mismo, está prohibida y puede ser ilegal. En dicho caso, por favor,
> notifíquelo al remitente y proceda a la eliminación de este correo
> electrónico, así como de sus adjuntos si los hubiere. En cumplimiento
> de la
> legislación española vigente en materia de protección de datos de
> carácter
> personal y del RGPD 679/2016 le informamos que sus datos están siendo
> objeto de tratamiento por parte de CODEOSCOPIC S.A. con CIFA85677342,
> con
> la finalidad del mantenimiento y gestión de relaciones comerciales y
> administrativas. La base jurídica del tratamiento es el interés
> legítimo de
> la empresa. No se prevén cesiones de sus datos, salvo que exista una
> obligación legal. Para ejercitar sus derechos puede dirigirse a
> CODEOSCOPIC
> S.A., domiciliada enPaseo de la Habana, 9-11, 28036 de Madrid
> (MADRID), o
> bien por email adpd@codeoscopic.com, con el fin de ejercer sus
> derechos de
> acceso, rectificación, supresión (derecho al olvido), limitación de
> tratamiento, portabilidad de los datos, oposición, y a no ser objeto de
> decisiones automatizadas, indicando como Asunto: “Derechos Ley
> Protección
> de Datos”, y adjuntando fotocopia de su DNI. Delegado de protección de
> datos:dpd@codeoscopic.com
>
>
>
Re: ROYALE_CLASS_INFO, renaming, modules, Objects
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Closure Compiler will rename (to a short name) any object and property on any object that isn't marked as "don’t rename" via several techniques:
1) Externs
2) @export
3) bracket syntax (i.e. obj["dontRenameThisProperty"])
4) having a getter and/or setter of the same name elsewhere in the compilation
By default, all Royale public and protected properties are marked as @export so they will never be renamed. That's what you want when deserializing network data or when folks might be using bracket syntax to access properties.
It "should be" ok for us and others to use plain objects than can be minified/renamed if needed. The key is being able to control what gets minified. I think #4 gives a way to control it.
HTH,
-Alex
On 12/12/18, 9:10 AM, "Carlos Rovira" <ca...@codeoscopic.com> wrote:
Hi Alex,
what do you mean with "prevent renaming"? there's some process that
implies a renaming? and renaming of what? the nested properties?
thanks
El mié., 12 dic. 2018 a las 17:21, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Using a plain object allows renaming. Using a class definition prevents
> renaming.
>
> Using shortnames in plain objects prevents renaming but is, IMO, a bad
> practice. Why make our code harder to read? It isn't just in the data
> structure, but in the code that reads it.
>
> -Alex
>
> On 12/12/18, 2:34 AM, "Carlos Rovira" <ca...@codeoscopic.com>
> wrote:
>
> Harb,
>
> That seems ok, but moreover...why don't we have a class definition
> instead
> a plain object, somethings like RoyaleClassInfo.as?
> Since Royale tries to enforce typing, I think using a plain object for
> royale class info, doesn't seems the most proper way to me
>
> thanks
>
>
>
> El mié., 12 dic. 2018 a las 11:23, Harbs (<ha...@gmail.com>)
> escribió:
>
> > Right, but I thought we already suggested single character names for
> the
> > ROYALE_CLASS_INFO object.
> >
> > To take one example:
> >
> org.apache.royale.html.supportClasses.Viewport.prototype.ROYALE_CLASS_INFO
> > = { names: [{ name: 'Viewport', qName:
> > 'org.apache.royale.html.supportClasses.Viewport', kind: 'class' }],
> > interfaces: [org.apache.royale.core.IBead,
> > org.apache.royale.core.IViewport] };
> >
> > That would become:
> >
> org.apache.royale.html.supportClasses.Viewport.prototype.ROYALE_CLASS_INFO
> > = { n: [{ n: 'Viewport', q:
> > 'org.apache.royale.html.supportClasses.Viewport', k: 'class' }], i:
> > [org.apache.royale.core.IBead, org.apache.royale.core.IViewport] };
> >
> > I’m pretty sure that’s enough to prevent renaming (because the
> closure
> > compiler does not rename single character variable names). If I’m
> wrong, we
> > could always output something like this:
> >
> >
> org.apache.royale.html.supportClasses.Viewport.prototype.ROYALE_CLASS_INFO
> > = { 'n': [{ 'n': 'Viewport', 'q':
> > 'org.apache.royale.html.supportClasses.Viewport', 'k': 'class' }],
> 'i':
> > [org.apache.royale.core.IBead, org.apache.royale.core.IViewport] };
> >
> > Am I missing something?
> > Harbs
> >
> > > On Dec 12, 2018, at 12:32 AM, Alex Harui <aharui@adobe.com.INVALID
> >
> > wrote:
> > >
> > > ROYALE_CLASS_INFO is a dynamic object. There is no class
> definition for
> > it, which means that its field names can be renamed.
> > >
> > > The whole point of modules is to load classes that aren't in the
> main
> > app so that the main app loads faster. So, if you have
> > >
> > > MainApp.mxml
> > > <mx:Application>
> > > <mx:ModuleLoader url="MyModule" />
> > > </mx:Application>
> > >
> > > MyModule.mxml
> > > <mx:Module>
> > > </mx:Module>
> > >
> > > The Language.is <
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flanguage.is%2F&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=qSasD0ckW6c6zl6hj9mXyBlFHUaTHFA6Usz6YZi0bGs%3D&reserved=0>
> function linked into Main app
> > might be checking for ROYALE_CLASS_INFO.interfaces and Application
> class
> > will have a ROYALE_CLASS_INFO.interfaces property. But Module might
> have
> > ROYALE_CLASS_INFO.i instead of interfaces. And thus Language.is <
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flanguage.is%2F&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=qSasD0ckW6c6zl6hj9mXyBlFHUaTHFA6Usz6YZi0bGs%3D&reserved=0>
> will not work on classes in the module. It depends
> > on what other code is in the main app. It appears that use of
> > Reflection.SWC's TypeDefinition in the main app tells the minifier
> to not
> > minify the "interfaces" property. Which means that any code an app
> > developer might add to the app could change the minification of
> > ROYALE_CLASS_INFO, or any other dynamic object.
> > >
> > > I'm trying to figure out why the minifier thinks the use of
> "interfaces"
> > in TypeDefinition matters but other attempts I've tried to force the
> > minifier to not rename "interfaces" in the module have not worked.
> > >
> > > HTH,
> > > -Alex
> > >
> > > On 12/11/18, 2:19 PM, "Harbs" <harbs.lists@gmail.com <mailto:
> > harbs.lists@gmail.com>> wrote:
> > >
> > > I’m still not getting the connection to ROYALE_CLASS_INFO.
> > >
> > > Can you explain to me in pseudo-code the problem with that? Why
> does
> > a dynamic object have ROYALE_CLASS_INFO at all?
> > >
> > >> On Dec 12, 2018, at 12:16 AM, Alex Harui <aharui@adobe.com.INVALID
> >
> > wrote:
> > >>
> > >> I'm not sure why you think it is theoretical. For sure, in TDF,
> the
> > module is not loading because ROYALE_CLASS_INFO is minified
> differently in
> > the main app than the module. Any dynamic objects shared across
> > compilations are at risk of being renamed differently. I'm chasing
> down a
> > way to control it.
> > >>
> > >> We do have control over the names of classes and properties to
> > guarantee they are the same in the app and module. It is just these
> > dynamic object keys that we don't yet have control over.
> > >>
> > >> We do have the option of defining a class for ROYALE_CLASS_INFO,
> but
> > then it will never minify. I like the fact that it can minify
> without us
> > having to use shortnames. It makes our debug code more readable and
> > doesn't waste space in small apps. Adding a class definition for
> > ROYALE_CLASS_INFO would further add overhead to small apps.
> > >>
> > >> My 2 cents,
> > >> -Alex
> > >>
> > >> On 12/11/18, 2:06 PM, "Harbs" <harbs.lists@gmail.com <mailto:
> > harbs.lists@gmail.com> <mailto:harbs.lists@gmail.com <mailto:
> > harbs.lists@gmail.com>>> wrote:
> > >>
> > >> In fact, in looking through the framework code so far, the only
> place
> > I’ve found variable names not quoted (in JS compatible code) so far
> was in
> > CSSUtils where we have a colorMap. I’m pretty sure the colorMap will
> not
> > work after minification because the color names will not match…
> > >>
> > >>> On Dec 12, 2018, at 12:01 AM, Harbs <harbs.lists@gmail.com
> <mailto:
> > harbs.lists@gmail.com>> wrote:
> > >>>
> > >>> Hi Carlos,
> > >>>
> > >>> We’re only discussing dynamic objects. How many of those do you
> have
> > in your applications? I doubt there’s much difference in performance
> due to
> > minification of dynamic objects.
> > >>>
> > >>> In *all* our framework code we have dynamic object instantiation
> in
> > 435 places including TLF, Spark and MX classes. Without those
> packages, I’m
> > estimating it’s a small fraction of that and probably most of the
> dynamic
> > objects are hash maps where they don’t benefit from minification
> anyway.
> > >>>
> > >>> The vast majority of the cases where you’re using dynamic
> objects in
> > production code you don’t want the names minified either (i.e. API
> calls
> > and uses of JSON).
> > >>>
> > >>> I think that most of this discussion is more theoretical than
> > practical considerations.
> > >>>
> > >>> My $0.02,
> > >>> Harbs
> > >>>
> > >>>> On Dec 11, 2018, at 11:26 PM, Carlos Rovira <
> carlosrovira@apache.org
> > <ma...@apache.org>> wrote:
> > >>>>
> > >>>> Hi,
> > >>>>
> > >>>> I'm still not using modules. I left that for now until we
> complete the
> > >>>> first phase in our project, but will be using (hopefully) around
> > February.
> > >>>>
> > >>>> So right now we're only using minification, that seems not only
> to
> > reduce
> > >>>> the size of the build, but release mode performs faster, and I
> think
> > is
> > >>>> due, in part, to minify.
> > >>>>
> > >>>> So, IMHO, as a user, I don't like A). Can't think of a solution,
> > since is
> > >>>> not my zone of expertise, and sure you guys found a good
> solution
> > after
> > >>>> all. Just want to say that as a user, is importante both
> things: have
> > >>>> modules (and hope we could link as well with routing like
> people do in
> > >>>> other current techs like React and Angular to get a powerful
> solution
> > for
> > >>>> SPAs) and have minification, since IMO, the resultant js-release
> > build has
> > >>>> many, many advantages, not only in performance and size but as
> well in
> > >>>> obfuscation, and for me is like our "binary output code".
> > >>>>
> > >>>> Sorry to not be able to give any suggestion, but maybe as well
> an
> > opinion
> > >>>> of use is as well valuable.
> > >>>>
> > >>>> just my 2
> > >>>>
> > >>>>
> > >>>> El mar., 11 dic. 2018 a las 21:24, Alex Harui
> > (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
> > >>>> escribió:
> > >>>>
> > >>>>> Thinking about it more, -js-dynamic-access probably won't
> help. We
> > don't
> > >>>>> want to compile our SWCs with that option on and thus turn off
> > minification
> > >>>>> of these field names always if we can help it.
> > >>>>>
> > >>>>> Even a directive per occurrence won't help either. Whether a
> field
> > name
> > >>>>> is renamed is still dependent on what other code is in the
> > compilation.
> > >>>>>
> > >>>>> The problem is better described as trying to find a way to
> control
> > what
> > >>>>> field names get renamed in more than one compilation, given
> that
> > there is
> > >>>>> pre-transpiled code that allows renaming. When building
> modules, we
> > >>>>> already require using Closure Compiler options that output the
> > renaming
> > >>>>> maps of the main app so that UIBase is given the same short
> name in
> > all
> > >>>>> minifications. But there is no way to dictate that for field
> names
> > as far
> > >>>>> as I can tell.
> > >>>>>
> > >>>>> -Alex
> > >>>>>
> > >>>>> On 12/11/18, 11:32 AM, "Harbs" <harbs.lists@gmail.com <mailto:
> > harbs.lists@gmail.com>> wrote:
> > >>>>>
> > >>>>> I vote for A.
> > >>>>>
> > >>>>> We can also do B which would require manually changing all
> access to
> > >>>>> brackets and quote all names in object literals.
> > >>>>>
> > >>>>> I might be nice to add some comment decorations to
> enable/disable
> > >>>>> -js-dynamic-access on a case-by-case basis, but I think it’s
> > reasonable to
> > >>>>> have a global on/off requirement. I’m already doing this for a
> > library I
> > >>>>> wrote which has a lot of dynamic data structures which does not
> > survive
> > >>>>> minification and the results are fine.
> > >>>>>
> > >>>>> My $0.02,
> > >>>>> Harbs
> > >>>>>
> > >>>>>> On Dec 11, 2018, at 8:47 PM, Alex Harui
> <aharui@adobe.com.INVALID
> > <ma...@adobe.com.INVALID>>
> > >>>>> wrote:
> > >>>>>>
> > >>>>>> IMO, some folks will want to rely on minification of object
> field
> > >>>>> names so save space. I think -js-dynamic-access blocks
> minification.
> > >>>>>>
> > >>>>>> So, to try to pose the problem another way, you can rely on
> > >>>>> minification object field names if you are building a
> single-js-file
> > app,
> > >>>>> but as soon as you start using modules, things may break. So
> what
> > should
> > >>>>> we tell folks?
> > >>>>>>
> > >>>>>> A) if you use modules you must turn off minification in
> objects with
> > >>>>> -js-dynamic-access
> > >>>>>> B) here are some ways to hack your code so you can still rely
> on
> > >>>>> minification
> > >>>>>> C) something else?
> > >>>>>>
> > >>>>>> We can manually rename fields in ROYALE_CLASS_INFO and other
> > >>>>> structures to make our code less readable in debug mode but
> save
> > space in
> > >>>>> release mode, but that does not solve the general case problem.
> > Folks may
> > >>>>> have other objects in their apps and modules that work until
> you add
> > some
> > >>>>> code to one of the projects that changes which object fields
> get
> > renamed.
> > >>>>>>
> > >>>>>> -Alex
> > >>>>>>
> > >>>>>> On 12/11/18, 9:31 AM, "Harbs" <harbs.lists@gmail.com <mailto:
> > harbs.lists@gmail.com>> wrote:
> > >>>>>>
> > >>>>>> I’m not following why this is the same point.
> > >>>>>>
> > >>>>>> I’m using -js-dynamic-access-unknown-members=true to handle
> this
> > >>>>> kind of problem. It works flawlessly…
> > >>>>>>
> > >>>>>> I’d personally argue that true should be the default, but
> whether
> > >>>>> the default is true or not, we do have an option to deal with
> these
> > kinds
> > >>>>> of data structures.
> > >>>>>>
> > >>>>>>> On Dec 11, 2018, at 6:39 PM, Alex Harui
> <aharui@adobe.com.INVALID
> > <ma...@adobe.com.INVALID>>
> > >>>>> wrote:
> > >>>>>>>
> > >>>>>>> Yes, we can use our own short names in code we generate, but
> that's
> > >>>>> not really the point.
> > >>>>>>>
> > >>>>>>> The point is that any plain object field can be renamed
> based on
> > >>>>> other code in the compile. So if you just have:
> > >>>>>>>
> > >>>>>>> Var obj:Object = { harbs: 1};
> > >>>>>>> Public static function foo()
> > >>>>>>> {
> > >>>>>>> Trace(obj.harbs);
> > >>>>>>> }
> > >>>>>>>
> > >>>>>>> Use of foo() in one compile may result in harbs being
> renamed, and
> > >>>>> another wouldn't. And that poses a problem when data
> structures are
> > shared
> > >>>>> between compiled outputs.
> > >>>>>>>
> > >>>>>>> This is a natural way to write AS, but the JS results when
> minified
> > >>>>> and shared between app and modules can fail. So what
> restrictions
> > should
> > >>>>> we place if any on how folks use plain objects?
> > >>>>>>>
> > >>>>>>> HTH,
> > >>>>>>> -Alex
> > >>>>>>>
> > >>>>>>> On 12/11/18, 7:36 AM, "Harbs" <harbs.lists@gmail.com
> <mailto:
> > harbs.lists@gmail.com>> wrote:
> > >>>>>>>
> > >>>>>>> I was about to make the same suggestion. We can use “I” for
> > >>>>> interfaces, “c” for class, “k” for kind, “n” for names. etc.
> > >>>>>>>
> > >>>>>>>> On Dec 11, 2018, at 2:52 PM, Frost, Andrew
> > <Andrew.Frost@Harman.com <ma...@Harman.com>>
> > >>>>> wrote:
> > >>>>>>>>
> > >>>>>>>> Hi
> > >>>>>>>>
> > >>>>>>>> Not sure that I fully understand this but would a valid
> compromise
> > >>>>> be something where the field name isn't renamed at all
> > automatically, but
> > >>>>> we just change it in the JS generation code to be "i" rather
> than
> > >>>>> "interfaces", and update the Language is/as functions to work
> with
> > this
> > >>>>> property name? Not sure whether it would work and I don't know
> > whether the
> > >>>>> Reflection stuff would then need to change too, but if this is
> all
> > in the
> > >>>>> generated outputs and/or the framework's own code then it
> shouldn't
> > be
> > >>>>> something that the end user would bother about..
> > >>>>>>>>
> > >>>>>>>> thanks
> > >>>>>>>>
> > >>>>>>>> Andrew
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> -----Original Message-----
> > >>>>>>>> From: Alex Harui [mailto:aharui@adobe.com.INVALID <mailto:
> > aharui@adobe.com.INVALID>]
> > >>>>>>>> Sent: 11 December 2018 08:32
> > >>>>>>>> To: dev@royale.apache.org <ma...@royale.apache.org>
> > >>>>>>>> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules,
> Objects
> > >>>>>>>>
> > >>>>>>>> I spent some time today trying to get Tour De Flex to run in
> > >>>>> production mode with the main app and modules being separately
> > minified.
> > >>>>>>>>
> > >>>>>>>> I've fixed a few things here and there, but an interesting
> issue I
> > >>>>> ran into has to do with the plain object we use in
> ROYALE_CLASS_INFO
> > (and
> > >>>>> will apply to other objects).
> > >>>>>>>>
> > >>>>>>>> The ROYALE_CLASS_INFO is generated on each class and has a
> "names"
> > >>>>> property and an optional "interfaces" property. An example is:
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>
> >
> org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO
> > >>>>> = { names: [{ name: 'PanelModel', qName:
> > >>>>> 'org.apache.royale.html.beads.models.PanelModel', kind:
> 'class' }],
> > >>>>> interfaces: [org.apache.royale.core.IBead,
> > >>>>> org.apache.royale.core.IPanelModel] };
> > >>>>>>>>
> > >>>>>>>> Because the field names are not quoted, then in most
> output, the
> > >>>>> field name "interfaces" is renamed and all code referencing
> this
> > field is
> > >>>>> renamed as well. This is good because it means that you don't
> have
> > to
> > >>>>> download the word "interfaces" once per-class. Instead of 10
> > characters, it
> > >>>>> is usually one or two. 100 classes saves you about 900 bytes.
> > >>>>>>>>
> > >>>>>>>> However, it turns out that in Tour De Flex, the main app
> uses
> > >>>>> Reflection and Reflection uses a quoted 'interfaces' string and
> > thus, the
> > >>>>> field name 'interfaces' in ROYALE_CLASS_INFO isn't renamed,
> but in
> > most
> > >>>>> modules "interfaces" is renamed since no other code in the
> module
> > has a
> > >>>>> quoted string for 'interfaces'. But that means that when a
> module
> > loads,
> > >>>>> the Language.is/as <
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flanguage.is%2Fas&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=yfr5w1B3EklIrmSVAoPV5T4ten96Qe%2F30TDHSHwS46w%3D&reserved=0>
> won't work since classes
> > in the main app are using
> > >>>>> "interfaces" but the classes in the module are using some
> short name.
> > >>>>>>>>
> > >>>>>>>> One solution is to always quote that field in the compiler
> output
> > >>>>> and Language is/as so it doesn't get renamed, but that means
> that
> > field
> > >>>>> will never get renamed and you lose saving those bytes.
> > >>>>>>>>
> > >>>>>>>> Another is let folks figure out their own workarounds, by
> adding
> > >>>>> some code that will prevent the renaming in the modules.
> > >>>>>>>>
> > >>>>>>>> Other ideas are welcome. I'm done for tonight.
> > >>>>>>>>
> > >>>>>>>> Thoughts?
> > >>>>>>>> -Alex
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>> --
> > >>>> Carlos Rovira
> > >>>>
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=d73eQkK3bbLvNUeINo%2BIJrHjgy9IT7qrANobYwGnKS0%3D&reserved=0
> > <
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=d73eQkK3bbLvNUeINo%2BIJrHjgy9IT7qrANobYwGnKS0%3D&reserved=0
> > ><
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=d73eQkK3bbLvNUeINo%2BIJrHjgy9IT7qrANobYwGnKS0%3D&reserved=0
> > <
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=d73eQkK3bbLvNUeINo%2BIJrHjgy9IT7qrANobYwGnKS0%3D&reserved=0
> > >>
> >
> >
>
> --
>
> <
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=nJPHUMexoC7saf7a6MrfOQWYf%2FYdpFJTTes%2Bmgjc%2BNE%3D&reserved=0
> >
>
> Carlos Rovira
>
> Presidente Ejecutivo
>
> M: +34 607 22 60 05
>
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=nJPHUMexoC7saf7a6MrfOQWYf%2FYdpFJTTes%2Bmgjc%2BNE%3D&reserved=0
>
>
> Conócenos en 1 minuto! <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favant2.es%2F%23video&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520696571&sdata=%2BS%2B5eRSKU%2B3URIdfVfza0%2Fph3VjUjrk5hWRGTJXEhi8%3D&reserved=0
> >
>
>
> AVISO LEGAL: La información contenida en este correo electrónico, y en
> su
> caso en los documentos adjuntos, es información privilegiada para uso
> exclusivo de la persona y/o personas a las que va dirigido. No está
> permitido el acceso a este mensaje a cualquier otra persona distinta a
> los
> indicados. Si Usted no es uno de los destinatarios, cualquier
> duplicación,
> reproducción, distribución, así como cualquier uso de la información
> contenida en él o cualquiera otra acción u omisión tomada en relación
> con
> el mismo, está prohibida y puede ser ilegal. En dicho caso, por favor,
> notifíquelo al remitente y proceda a la eliminación de este correo
> electrónico, así como de sus adjuntos si los hubiere. En cumplimiento
> de la
> legislación española vigente en materia de protección de datos de
> carácter
> personal y del RGPD 679/2016 le informamos que sus datos están siendo
> objeto de tratamiento por parte de CODEOSCOPIC S.A. con CIFA85677342,
> con
> la finalidad del mantenimiento y gestión de relaciones comerciales y
> administrativas. La base jurídica del tratamiento es el interés
> legítimo de
> la empresa. No se prevén cesiones de sus datos, salvo que exista una
> obligación legal. Para ejercitar sus derechos puede dirigirse a
> CODEOSCOPIC
> S.A., domiciliada enPaseo de la Habana, 9-11, 28036 de Madrid
> (MADRID), o
> bien por email adpd@codeoscopic.com, con el fin de ejercer sus
> derechos de
> acceso, rectificación, supresión (derecho al olvido), limitación de
> tratamiento, portabilidad de los datos, oposición, y a no ser objeto de
> decisiones automatizadas, indicando como Asunto: “Derechos Ley
> Protección
> de Datos”, y adjuntando fotocopia de su DNI. Delegado de protección de
> datos:dpd@codeoscopic.com
>
>
>
--
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520696571&sdata=6PTVtYdOOp3s4eF0zwTq7uRo5xxpbvl1T3TZdUIY20g%3D&reserved=0>
Carlos Rovira
Presidente Ejecutivo
M: +34 607 22 60 05
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520696571&sdata=6PTVtYdOOp3s4eF0zwTq7uRo5xxpbvl1T3TZdUIY20g%3D&reserved=0
Conócenos en 1 minuto! <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favant2.es%2F%23video&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520696571&sdata=%2BS%2B5eRSKU%2B3URIdfVfza0%2Fph3VjUjrk5hWRGTJXEhi8%3D&reserved=0>
AVISO LEGAL: La información contenida en este correo electrónico, y en su
caso en los documentos adjuntos, es información privilegiada para uso
exclusivo de la persona y/o personas a las que va dirigido. No está
permitido el acceso a este mensaje a cualquier otra persona distinta a los
indicados. Si Usted no es uno de los destinatarios, cualquier duplicación,
reproducción, distribución, así como cualquier uso de la información
contenida en él o cualquiera otra acción u omisión tomada en relación con
el mismo, está prohibida y puede ser ilegal. En dicho caso, por favor,
notifíquelo al remitente y proceda a la eliminación de este correo
electrónico, así como de sus adjuntos si los hubiere. En cumplimiento de la
legislación española vigente en materia de protección de datos de carácter
personal y del RGPD 679/2016 le informamos que sus datos están siendo
objeto de tratamiento por parte de CODEOSCOPIC S.A. con CIFA85677342, con
la finalidad del mantenimiento y gestión de relaciones comerciales y
administrativas. La base jurídica del tratamiento es el interés legítimo de
la empresa. No se prevén cesiones de sus datos, salvo que exista una
obligación legal. Para ejercitar sus derechos puede dirigirse a CODEOSCOPIC
S.A., domiciliada enPaseo de la Habana, 9-11, 28036 de Madrid (MADRID), o
bien por email adpd@codeoscopic.com, con el fin de ejercer sus derechos de
acceso, rectificación, supresión (derecho al olvido), limitación de
tratamiento, portabilidad de los datos, oposición, y a no ser objeto de
decisiones automatizadas, indicando como Asunto: “Derechos Ley Protección
de Datos”, y adjuntando fotocopia de su DNI. Delegado de protección de
datos:dpd@codeoscopic.com
Re: ROYALE_CLASS_INFO, renaming, modules, Objects
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Alex,
what do you mean with "prevent renaming"? there's some process that
implies a renaming? and renaming of what? the nested properties?
thanks
El mié., 12 dic. 2018 a las 17:21, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Using a plain object allows renaming. Using a class definition prevents
> renaming.
>
> Using shortnames in plain objects prevents renaming but is, IMO, a bad
> practice. Why make our code harder to read? It isn't just in the data
> structure, but in the code that reads it.
>
> -Alex
>
> On 12/12/18, 2:34 AM, "Carlos Rovira" <ca...@codeoscopic.com>
> wrote:
>
> Harb,
>
> That seems ok, but moreover...why don't we have a class definition
> instead
> a plain object, somethings like RoyaleClassInfo.as?
> Since Royale tries to enforce typing, I think using a plain object for
> royale class info, doesn't seems the most proper way to me
>
> thanks
>
>
>
> El mié., 12 dic. 2018 a las 11:23, Harbs (<ha...@gmail.com>)
> escribió:
>
> > Right, but I thought we already suggested single character names for
> the
> > ROYALE_CLASS_INFO object.
> >
> > To take one example:
> >
> org.apache.royale.html.supportClasses.Viewport.prototype.ROYALE_CLASS_INFO
> > = { names: [{ name: 'Viewport', qName:
> > 'org.apache.royale.html.supportClasses.Viewport', kind: 'class' }],
> > interfaces: [org.apache.royale.core.IBead,
> > org.apache.royale.core.IViewport] };
> >
> > That would become:
> >
> org.apache.royale.html.supportClasses.Viewport.prototype.ROYALE_CLASS_INFO
> > = { n: [{ n: 'Viewport', q:
> > 'org.apache.royale.html.supportClasses.Viewport', k: 'class' }], i:
> > [org.apache.royale.core.IBead, org.apache.royale.core.IViewport] };
> >
> > I’m pretty sure that’s enough to prevent renaming (because the
> closure
> > compiler does not rename single character variable names). If I’m
> wrong, we
> > could always output something like this:
> >
> >
> org.apache.royale.html.supportClasses.Viewport.prototype.ROYALE_CLASS_INFO
> > = { 'n': [{ 'n': 'Viewport', 'q':
> > 'org.apache.royale.html.supportClasses.Viewport', 'k': 'class' }],
> 'i':
> > [org.apache.royale.core.IBead, org.apache.royale.core.IViewport] };
> >
> > Am I missing something?
> > Harbs
> >
> > > On Dec 12, 2018, at 12:32 AM, Alex Harui <aharui@adobe.com.INVALID
> >
> > wrote:
> > >
> > > ROYALE_CLASS_INFO is a dynamic object. There is no class
> definition for
> > it, which means that its field names can be renamed.
> > >
> > > The whole point of modules is to load classes that aren't in the
> main
> > app so that the main app loads faster. So, if you have
> > >
> > > MainApp.mxml
> > > <mx:Application>
> > > <mx:ModuleLoader url="MyModule" />
> > > </mx:Application>
> > >
> > > MyModule.mxml
> > > <mx:Module>
> > > </mx:Module>
> > >
> > > The Language.is <
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flanguage.is%2F&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925068534&sdata=5VGfoczFg35bUnerVM144kIlrvfXuWd5m%2BpetEW%2FY74%3D&reserved=0>
> function linked into Main app
> > might be checking for ROYALE_CLASS_INFO.interfaces and Application
> class
> > will have a ROYALE_CLASS_INFO.interfaces property. But Module might
> have
> > ROYALE_CLASS_INFO.i instead of interfaces. And thus Language.is <
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flanguage.is%2F&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=zsy%2FoU9vn%2BoGUd5Ri57fHeqW5wbzhqvo1lXlgZWwkCY%3D&reserved=0>
> will not work on classes in the module. It depends
> > on what other code is in the main app. It appears that use of
> > Reflection.SWC's TypeDefinition in the main app tells the minifier
> to not
> > minify the "interfaces" property. Which means that any code an app
> > developer might add to the app could change the minification of
> > ROYALE_CLASS_INFO, or any other dynamic object.
> > >
> > > I'm trying to figure out why the minifier thinks the use of
> "interfaces"
> > in TypeDefinition matters but other attempts I've tried to force the
> > minifier to not rename "interfaces" in the module have not worked.
> > >
> > > HTH,
> > > -Alex
> > >
> > > On 12/11/18, 2:19 PM, "Harbs" <harbs.lists@gmail.com <mailto:
> > harbs.lists@gmail.com>> wrote:
> > >
> > > I’m still not getting the connection to ROYALE_CLASS_INFO.
> > >
> > > Can you explain to me in pseudo-code the problem with that? Why
> does
> > a dynamic object have ROYALE_CLASS_INFO at all?
> > >
> > >> On Dec 12, 2018, at 12:16 AM, Alex Harui <aharui@adobe.com.INVALID
> >
> > wrote:
> > >>
> > >> I'm not sure why you think it is theoretical. For sure, in TDF,
> the
> > module is not loading because ROYALE_CLASS_INFO is minified
> differently in
> > the main app than the module. Any dynamic objects shared across
> > compilations are at risk of being renamed differently. I'm chasing
> down a
> > way to control it.
> > >>
> > >> We do have control over the names of classes and properties to
> > guarantee they are the same in the app and module. It is just these
> > dynamic object keys that we don't yet have control over.
> > >>
> > >> We do have the option of defining a class for ROYALE_CLASS_INFO,
> but
> > then it will never minify. I like the fact that it can minify
> without us
> > having to use shortnames. It makes our debug code more readable and
> > doesn't waste space in small apps. Adding a class definition for
> > ROYALE_CLASS_INFO would further add overhead to small apps.
> > >>
> > >> My 2 cents,
> > >> -Alex
> > >>
> > >> On 12/11/18, 2:06 PM, "Harbs" <harbs.lists@gmail.com <mailto:
> > harbs.lists@gmail.com> <mailto:harbs.lists@gmail.com <mailto:
> > harbs.lists@gmail.com>>> wrote:
> > >>
> > >> In fact, in looking through the framework code so far, the only
> place
> > I’ve found variable names not quoted (in JS compatible code) so far
> was in
> > CSSUtils where we have a colorMap. I’m pretty sure the colorMap will
> not
> > work after minification because the color names will not match…
> > >>
> > >>> On Dec 12, 2018, at 12:01 AM, Harbs <harbs.lists@gmail.com
> <mailto:
> > harbs.lists@gmail.com>> wrote:
> > >>>
> > >>> Hi Carlos,
> > >>>
> > >>> We’re only discussing dynamic objects. How many of those do you
> have
> > in your applications? I doubt there’s much difference in performance
> due to
> > minification of dynamic objects.
> > >>>
> > >>> In *all* our framework code we have dynamic object instantiation
> in
> > 435 places including TLF, Spark and MX classes. Without those
> packages, I’m
> > estimating it’s a small fraction of that and probably most of the
> dynamic
> > objects are hash maps where they don’t benefit from minification
> anyway.
> > >>>
> > >>> The vast majority of the cases where you’re using dynamic
> objects in
> > production code you don’t want the names minified either (i.e. API
> calls
> > and uses of JSON).
> > >>>
> > >>> I think that most of this discussion is more theoretical than
> > practical considerations.
> > >>>
> > >>> My $0.02,
> > >>> Harbs
> > >>>
> > >>>> On Dec 11, 2018, at 11:26 PM, Carlos Rovira <
> carlosrovira@apache.org
> > <ma...@apache.org>> wrote:
> > >>>>
> > >>>> Hi,
> > >>>>
> > >>>> I'm still not using modules. I left that for now until we
> complete the
> > >>>> first phase in our project, but will be using (hopefully) around
> > February.
> > >>>>
> > >>>> So right now we're only using minification, that seems not only
> to
> > reduce
> > >>>> the size of the build, but release mode performs faster, and I
> think
> > is
> > >>>> due, in part, to minify.
> > >>>>
> > >>>> So, IMHO, as a user, I don't like A). Can't think of a solution,
> > since is
> > >>>> not my zone of expertise, and sure you guys found a good
> solution
> > after
> > >>>> all. Just want to say that as a user, is importante both
> things: have
> > >>>> modules (and hope we could link as well with routing like
> people do in
> > >>>> other current techs like React and Angular to get a powerful
> solution
> > for
> > >>>> SPAs) and have minification, since IMO, the resultant js-release
> > build has
> > >>>> many, many advantages, not only in performance and size but as
> well in
> > >>>> obfuscation, and for me is like our "binary output code".
> > >>>>
> > >>>> Sorry to not be able to give any suggestion, but maybe as well
> an
> > opinion
> > >>>> of use is as well valuable.
> > >>>>
> > >>>> just my 2
> > >>>>
> > >>>>
> > >>>> El mar., 11 dic. 2018 a las 21:24, Alex Harui
> > (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
> > >>>> escribió:
> > >>>>
> > >>>>> Thinking about it more, -js-dynamic-access probably won't
> help. We
> > don't
> > >>>>> want to compile our SWCs with that option on and thus turn off
> > minification
> > >>>>> of these field names always if we can help it.
> > >>>>>
> > >>>>> Even a directive per occurrence won't help either. Whether a
> field
> > name
> > >>>>> is renamed is still dependent on what other code is in the
> > compilation.
> > >>>>>
> > >>>>> The problem is better described as trying to find a way to
> control
> > what
> > >>>>> field names get renamed in more than one compilation, given
> that
> > there is
> > >>>>> pre-transpiled code that allows renaming. When building
> modules, we
> > >>>>> already require using Closure Compiler options that output the
> > renaming
> > >>>>> maps of the main app so that UIBase is given the same short
> name in
> > all
> > >>>>> minifications. But there is no way to dictate that for field
> names
> > as far
> > >>>>> as I can tell.
> > >>>>>
> > >>>>> -Alex
> > >>>>>
> > >>>>> On 12/11/18, 11:32 AM, "Harbs" <harbs.lists@gmail.com <mailto:
> > harbs.lists@gmail.com>> wrote:
> > >>>>>
> > >>>>> I vote for A.
> > >>>>>
> > >>>>> We can also do B which would require manually changing all
> access to
> > >>>>> brackets and quote all names in object literals.
> > >>>>>
> > >>>>> I might be nice to add some comment decorations to
> enable/disable
> > >>>>> -js-dynamic-access on a case-by-case basis, but I think it’s
> > reasonable to
> > >>>>> have a global on/off requirement. I’m already doing this for a
> > library I
> > >>>>> wrote which has a lot of dynamic data structures which does not
> > survive
> > >>>>> minification and the results are fine.
> > >>>>>
> > >>>>> My $0.02,
> > >>>>> Harbs
> > >>>>>
> > >>>>>> On Dec 11, 2018, at 8:47 PM, Alex Harui
> <aharui@adobe.com.INVALID
> > <ma...@adobe.com.INVALID>>
> > >>>>> wrote:
> > >>>>>>
> > >>>>>> IMO, some folks will want to rely on minification of object
> field
> > >>>>> names so save space. I think -js-dynamic-access blocks
> minification.
> > >>>>>>
> > >>>>>> So, to try to pose the problem another way, you can rely on
> > >>>>> minification object field names if you are building a
> single-js-file
> > app,
> > >>>>> but as soon as you start using modules, things may break. So
> what
> > should
> > >>>>> we tell folks?
> > >>>>>>
> > >>>>>> A) if you use modules you must turn off minification in
> objects with
> > >>>>> -js-dynamic-access
> > >>>>>> B) here are some ways to hack your code so you can still rely
> on
> > >>>>> minification
> > >>>>>> C) something else?
> > >>>>>>
> > >>>>>> We can manually rename fields in ROYALE_CLASS_INFO and other
> > >>>>> structures to make our code less readable in debug mode but
> save
> > space in
> > >>>>> release mode, but that does not solve the general case problem.
> > Folks may
> > >>>>> have other objects in their apps and modules that work until
> you add
> > some
> > >>>>> code to one of the projects that changes which object fields
> get
> > renamed.
> > >>>>>>
> > >>>>>> -Alex
> > >>>>>>
> > >>>>>> On 12/11/18, 9:31 AM, "Harbs" <harbs.lists@gmail.com <mailto:
> > harbs.lists@gmail.com>> wrote:
> > >>>>>>
> > >>>>>> I’m not following why this is the same point.
> > >>>>>>
> > >>>>>> I’m using -js-dynamic-access-unknown-members=true to handle
> this
> > >>>>> kind of problem. It works flawlessly…
> > >>>>>>
> > >>>>>> I’d personally argue that true should be the default, but
> whether
> > >>>>> the default is true or not, we do have an option to deal with
> these
> > kinds
> > >>>>> of data structures.
> > >>>>>>
> > >>>>>>> On Dec 11, 2018, at 6:39 PM, Alex Harui
> <aharui@adobe.com.INVALID
> > <ma...@adobe.com.INVALID>>
> > >>>>> wrote:
> > >>>>>>>
> > >>>>>>> Yes, we can use our own short names in code we generate, but
> that's
> > >>>>> not really the point.
> > >>>>>>>
> > >>>>>>> The point is that any plain object field can be renamed
> based on
> > >>>>> other code in the compile. So if you just have:
> > >>>>>>>
> > >>>>>>> Var obj:Object = { harbs: 1};
> > >>>>>>> Public static function foo()
> > >>>>>>> {
> > >>>>>>> Trace(obj.harbs);
> > >>>>>>> }
> > >>>>>>>
> > >>>>>>> Use of foo() in one compile may result in harbs being
> renamed, and
> > >>>>> another wouldn't. And that poses a problem when data
> structures are
> > shared
> > >>>>> between compiled outputs.
> > >>>>>>>
> > >>>>>>> This is a natural way to write AS, but the JS results when
> minified
> > >>>>> and shared between app and modules can fail. So what
> restrictions
> > should
> > >>>>> we place if any on how folks use plain objects?
> > >>>>>>>
> > >>>>>>> HTH,
> > >>>>>>> -Alex
> > >>>>>>>
> > >>>>>>> On 12/11/18, 7:36 AM, "Harbs" <harbs.lists@gmail.com
> <mailto:
> > harbs.lists@gmail.com>> wrote:
> > >>>>>>>
> > >>>>>>> I was about to make the same suggestion. We can use “I” for
> > >>>>> interfaces, “c” for class, “k” for kind, “n” for names. etc.
> > >>>>>>>
> > >>>>>>>> On Dec 11, 2018, at 2:52 PM, Frost, Andrew
> > <Andrew.Frost@Harman.com <ma...@Harman.com>>
> > >>>>> wrote:
> > >>>>>>>>
> > >>>>>>>> Hi
> > >>>>>>>>
> > >>>>>>>> Not sure that I fully understand this but would a valid
> compromise
> > >>>>> be something where the field name isn't renamed at all
> > automatically, but
> > >>>>> we just change it in the JS generation code to be "i" rather
> than
> > >>>>> "interfaces", and update the Language is/as functions to work
> with
> > this
> > >>>>> property name? Not sure whether it would work and I don't know
> > whether the
> > >>>>> Reflection stuff would then need to change too, but if this is
> all
> > in the
> > >>>>> generated outputs and/or the framework's own code then it
> shouldn't
> > be
> > >>>>> something that the end user would bother about..
> > >>>>>>>>
> > >>>>>>>> thanks
> > >>>>>>>>
> > >>>>>>>> Andrew
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> -----Original Message-----
> > >>>>>>>> From: Alex Harui [mailto:aharui@adobe.com.INVALID <mailto:
> > aharui@adobe.com.INVALID>]
> > >>>>>>>> Sent: 11 December 2018 08:32
> > >>>>>>>> To: dev@royale.apache.org <ma...@royale.apache.org>
> > >>>>>>>> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules,
> Objects
> > >>>>>>>>
> > >>>>>>>> I spent some time today trying to get Tour De Flex to run in
> > >>>>> production mode with the main app and modules being separately
> > minified.
> > >>>>>>>>
> > >>>>>>>> I've fixed a few things here and there, but an interesting
> issue I
> > >>>>> ran into has to do with the plain object we use in
> ROYALE_CLASS_INFO
> > (and
> > >>>>> will apply to other objects).
> > >>>>>>>>
> > >>>>>>>> The ROYALE_CLASS_INFO is generated on each class and has a
> "names"
> > >>>>> property and an optional "interfaces" property. An example is:
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>
> >
> org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO
> > >>>>> = { names: [{ name: 'PanelModel', qName:
> > >>>>> 'org.apache.royale.html.beads.models.PanelModel', kind:
> 'class' }],
> > >>>>> interfaces: [org.apache.royale.core.IBead,
> > >>>>> org.apache.royale.core.IPanelModel] };
> > >>>>>>>>
> > >>>>>>>> Because the field names are not quoted, then in most
> output, the
> > >>>>> field name "interfaces" is renamed and all code referencing
> this
> > field is
> > >>>>> renamed as well. This is good because it means that you don't
> have
> > to
> > >>>>> download the word "interfaces" once per-class. Instead of 10
> > characters, it
> > >>>>> is usually one or two. 100 classes saves you about 900 bytes.
> > >>>>>>>>
> > >>>>>>>> However, it turns out that in Tour De Flex, the main app
> uses
> > >>>>> Reflection and Reflection uses a quoted 'interfaces' string and
> > thus, the
> > >>>>> field name 'interfaces' in ROYALE_CLASS_INFO isn't renamed,
> but in
> > most
> > >>>>> modules "interfaces" is renamed since no other code in the
> module
> > has a
> > >>>>> quoted string for 'interfaces'. But that means that when a
> module
> > loads,
> > >>>>> the Language.is/as <
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flanguage.is%2Fas&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=o%2FC8K1KRrYdkwLuQfkLG3tU2AlVRLGlaShPm37U5p8s%3D&reserved=0>
> won't work since classes
> > in the main app are using
> > >>>>> "interfaces" but the classes in the module are using some
> short name.
> > >>>>>>>>
> > >>>>>>>> One solution is to always quote that field in the compiler
> output
> > >>>>> and Language is/as so it doesn't get renamed, but that means
> that
> > field
> > >>>>> will never get renamed and you lose saving those bytes.
> > >>>>>>>>
> > >>>>>>>> Another is let folks figure out their own workarounds, by
> adding
> > >>>>> some code that will prevent the renaming in the modules.
> > >>>>>>>>
> > >>>>>>>> Other ideas are welcome. I'm done for tonight.
> > >>>>>>>>
> > >>>>>>>> Thoughts?
> > >>>>>>>> -Alex
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>> --
> > >>>> Carlos Rovira
> > >>>>
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=MnCmCfYt2uepmueMxwDcMFE0Ah60sJxFa7Kg2wBTa00%3D&reserved=0
> > <
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=MnCmCfYt2uepmueMxwDcMFE0Ah60sJxFa7Kg2wBTa00%3D&reserved=0
> > ><
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=MnCmCfYt2uepmueMxwDcMFE0Ah60sJxFa7Kg2wBTa00%3D&reserved=0
> > <
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=MnCmCfYt2uepmueMxwDcMFE0Ah60sJxFa7Kg2wBTa00%3D&reserved=0
> > >>
> >
> >
>
> --
>
> <
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=eT5WhToYF5NCxjWsGbIWaLx86wBOUDg%2B%2BCjgct9XJr4%3D&reserved=0
> >
>
> Carlos Rovira
>
> Presidente Ejecutivo
>
> M: +34 607 22 60 05
>
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=eT5WhToYF5NCxjWsGbIWaLx86wBOUDg%2B%2BCjgct9XJr4%3D&reserved=0
>
>
> Conócenos en 1 minuto! <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favant2.es%2F%23video&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=HCsi5N6f87s7jX04eVfmVGT0J1IlGJ823VaKDSxHCbo%3D&reserved=0
> >
>
>
> AVISO LEGAL: La información contenida en este correo electrónico, y en
> su
> caso en los documentos adjuntos, es información privilegiada para uso
> exclusivo de la persona y/o personas a las que va dirigido. No está
> permitido el acceso a este mensaje a cualquier otra persona distinta a
> los
> indicados. Si Usted no es uno de los destinatarios, cualquier
> duplicación,
> reproducción, distribución, así como cualquier uso de la información
> contenida en él o cualquiera otra acción u omisión tomada en relación
> con
> el mismo, está prohibida y puede ser ilegal. En dicho caso, por favor,
> notifíquelo al remitente y proceda a la eliminación de este correo
> electrónico, así como de sus adjuntos si los hubiere. En cumplimiento
> de la
> legislación española vigente en materia de protección de datos de
> carácter
> personal y del RGPD 679/2016 le informamos que sus datos están siendo
> objeto de tratamiento por parte de CODEOSCOPIC S.A. con CIFA85677342,
> con
> la finalidad del mantenimiento y gestión de relaciones comerciales y
> administrativas. La base jurídica del tratamiento es el interés
> legítimo de
> la empresa. No se prevén cesiones de sus datos, salvo que exista una
> obligación legal. Para ejercitar sus derechos puede dirigirse a
> CODEOSCOPIC
> S.A., domiciliada enPaseo de la Habana, 9-11, 28036 de Madrid
> (MADRID), o
> bien por email adpd@codeoscopic.com, con el fin de ejercer sus
> derechos de
> acceso, rectificación, supresión (derecho al olvido), limitación de
> tratamiento, portabilidad de los datos, oposición, y a no ser objeto de
> decisiones automatizadas, indicando como Asunto: “Derechos Ley
> Protección
> de Datos”, y adjuntando fotocopia de su DNI. Delegado de protección de
> datos:dpd@codeoscopic.com
>
>
>
--
<http://www.codeoscopic.com>
Carlos Rovira
Presidente Ejecutivo
M: +34 607 22 60 05
http://www.codeoscopic.com
Conócenos en 1 minuto! <https://avant2.es/#video>
AVISO LEGAL: La información contenida en este correo electrónico, y en su
caso en los documentos adjuntos, es información privilegiada para uso
exclusivo de la persona y/o personas a las que va dirigido. No está
permitido el acceso a este mensaje a cualquier otra persona distinta a los
indicados. Si Usted no es uno de los destinatarios, cualquier duplicación,
reproducción, distribución, así como cualquier uso de la información
contenida en él o cualquiera otra acción u omisión tomada en relación con
el mismo, está prohibida y puede ser ilegal. En dicho caso, por favor,
notifíquelo al remitente y proceda a la eliminación de este correo
electrónico, así como de sus adjuntos si los hubiere. En cumplimiento de la
legislación española vigente en materia de protección de datos de carácter
personal y del RGPD 679/2016 le informamos que sus datos están siendo
objeto de tratamiento por parte de CODEOSCOPIC S.A. con CIFA85677342, con
la finalidad del mantenimiento y gestión de relaciones comerciales y
administrativas. La base jurídica del tratamiento es el interés legítimo de
la empresa. No se prevén cesiones de sus datos, salvo que exista una
obligación legal. Para ejercitar sus derechos puede dirigirse a CODEOSCOPIC
S.A., domiciliada enPaseo de la Habana, 9-11, 28036 de Madrid (MADRID), o
bien por email adpd@codeoscopic.com, con el fin de ejercer sus derechos de
acceso, rectificación, supresión (derecho al olvido), limitación de
tratamiento, portabilidad de los datos, oposición, y a no ser objeto de
decisiones automatizadas, indicando como Asunto: “Derechos Ley Protección
de Datos”, y adjuntando fotocopia de su DNI. Delegado de protección de
datos:dpd@codeoscopic.com
Re: ROYALE_CLASS_INFO, renaming, modules, Objects
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Using a plain object allows renaming. Using a class definition prevents renaming.
Using shortnames in plain objects prevents renaming but is, IMO, a bad practice. Why make our code harder to read? It isn't just in the data structure, but in the code that reads it.
-Alex
On 12/12/18, 2:34 AM, "Carlos Rovira" <ca...@codeoscopic.com> wrote:
Harb,
That seems ok, but moreover...why don't we have a class definition instead
a plain object, somethings like RoyaleClassInfo.as?
Since Royale tries to enforce typing, I think using a plain object for
royale class info, doesn't seems the most proper way to me
thanks
El mié., 12 dic. 2018 a las 11:23, Harbs (<ha...@gmail.com>) escribió:
> Right, but I thought we already suggested single character names for the
> ROYALE_CLASS_INFO object.
>
> To take one example:
> org.apache.royale.html.supportClasses.Viewport.prototype.ROYALE_CLASS_INFO
> = { names: [{ name: 'Viewport', qName:
> 'org.apache.royale.html.supportClasses.Viewport', kind: 'class' }],
> interfaces: [org.apache.royale.core.IBead,
> org.apache.royale.core.IViewport] };
>
> That would become:
> org.apache.royale.html.supportClasses.Viewport.prototype.ROYALE_CLASS_INFO
> = { n: [{ n: 'Viewport', q:
> 'org.apache.royale.html.supportClasses.Viewport', k: 'class' }], i:
> [org.apache.royale.core.IBead, org.apache.royale.core.IViewport] };
>
> I’m pretty sure that’s enough to prevent renaming (because the closure
> compiler does not rename single character variable names). If I’m wrong, we
> could always output something like this:
>
> org.apache.royale.html.supportClasses.Viewport.prototype.ROYALE_CLASS_INFO
> = { 'n': [{ 'n': 'Viewport', 'q':
> 'org.apache.royale.html.supportClasses.Viewport', 'k': 'class' }], 'i':
> [org.apache.royale.core.IBead, org.apache.royale.core.IViewport] };
>
> Am I missing something?
> Harbs
>
> > On Dec 12, 2018, at 12:32 AM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >
> > ROYALE_CLASS_INFO is a dynamic object. There is no class definition for
> it, which means that its field names can be renamed.
> >
> > The whole point of modules is to load classes that aren't in the main
> app so that the main app loads faster. So, if you have
> >
> > MainApp.mxml
> > <mx:Application>
> > <mx:ModuleLoader url="MyModule" />
> > </mx:Application>
> >
> > MyModule.mxml
> > <mx:Module>
> > </mx:Module>
> >
> > The Language.is <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flanguage.is%2F&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925068534&sdata=5VGfoczFg35bUnerVM144kIlrvfXuWd5m%2BpetEW%2FY74%3D&reserved=0> function linked into Main app
> might be checking for ROYALE_CLASS_INFO.interfaces and Application class
> will have a ROYALE_CLASS_INFO.interfaces property. But Module might have
> ROYALE_CLASS_INFO.i instead of interfaces. And thus Language.is <
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flanguage.is%2F&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=zsy%2FoU9vn%2BoGUd5Ri57fHeqW5wbzhqvo1lXlgZWwkCY%3D&reserved=0> will not work on classes in the module. It depends
> on what other code is in the main app. It appears that use of
> Reflection.SWC's TypeDefinition in the main app tells the minifier to not
> minify the "interfaces" property. Which means that any code an app
> developer might add to the app could change the minification of
> ROYALE_CLASS_INFO, or any other dynamic object.
> >
> > I'm trying to figure out why the minifier thinks the use of "interfaces"
> in TypeDefinition matters but other attempts I've tried to force the
> minifier to not rename "interfaces" in the module have not worked.
> >
> > HTH,
> > -Alex
> >
> > On 12/11/18, 2:19 PM, "Harbs" <harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com>> wrote:
> >
> > I’m still not getting the connection to ROYALE_CLASS_INFO.
> >
> > Can you explain to me in pseudo-code the problem with that? Why does
> a dynamic object have ROYALE_CLASS_INFO at all?
> >
> >> On Dec 12, 2018, at 12:16 AM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >>
> >> I'm not sure why you think it is theoretical. For sure, in TDF, the
> module is not loading because ROYALE_CLASS_INFO is minified differently in
> the main app than the module. Any dynamic objects shared across
> compilations are at risk of being renamed differently. I'm chasing down a
> way to control it.
> >>
> >> We do have control over the names of classes and properties to
> guarantee they are the same in the app and module. It is just these
> dynamic object keys that we don't yet have control over.
> >>
> >> We do have the option of defining a class for ROYALE_CLASS_INFO, but
> then it will never minify. I like the fact that it can minify without us
> having to use shortnames. It makes our debug code more readable and
> doesn't waste space in small apps. Adding a class definition for
> ROYALE_CLASS_INFO would further add overhead to small apps.
> >>
> >> My 2 cents,
> >> -Alex
> >>
> >> On 12/11/18, 2:06 PM, "Harbs" <harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com> <mailto:harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com>>> wrote:
> >>
> >> In fact, in looking through the framework code so far, the only place
> I’ve found variable names not quoted (in JS compatible code) so far was in
> CSSUtils where we have a colorMap. I’m pretty sure the colorMap will not
> work after minification because the color names will not match…
> >>
> >>> On Dec 12, 2018, at 12:01 AM, Harbs <harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com>> wrote:
> >>>
> >>> Hi Carlos,
> >>>
> >>> We’re only discussing dynamic objects. How many of those do you have
> in your applications? I doubt there’s much difference in performance due to
> minification of dynamic objects.
> >>>
> >>> In *all* our framework code we have dynamic object instantiation in
> 435 places including TLF, Spark and MX classes. Without those packages, I’m
> estimating it’s a small fraction of that and probably most of the dynamic
> objects are hash maps where they don’t benefit from minification anyway.
> >>>
> >>> The vast majority of the cases where you’re using dynamic objects in
> production code you don’t want the names minified either (i.e. API calls
> and uses of JSON).
> >>>
> >>> I think that most of this discussion is more theoretical than
> practical considerations.
> >>>
> >>> My $0.02,
> >>> Harbs
> >>>
> >>>> On Dec 11, 2018, at 11:26 PM, Carlos Rovira <carlosrovira@apache.org
> <ma...@apache.org>> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> I'm still not using modules. I left that for now until we complete the
> >>>> first phase in our project, but will be using (hopefully) around
> February.
> >>>>
> >>>> So right now we're only using minification, that seems not only to
> reduce
> >>>> the size of the build, but release mode performs faster, and I think
> is
> >>>> due, in part, to minify.
> >>>>
> >>>> So, IMHO, as a user, I don't like A). Can't think of a solution,
> since is
> >>>> not my zone of expertise, and sure you guys found a good solution
> after
> >>>> all. Just want to say that as a user, is importante both things: have
> >>>> modules (and hope we could link as well with routing like people do in
> >>>> other current techs like React and Angular to get a powerful solution
> for
> >>>> SPAs) and have minification, since IMO, the resultant js-release
> build has
> >>>> many, many advantages, not only in performance and size but as well in
> >>>> obfuscation, and for me is like our "binary output code".
> >>>>
> >>>> Sorry to not be able to give any suggestion, but maybe as well an
> opinion
> >>>> of use is as well valuable.
> >>>>
> >>>> just my 2
> >>>>
> >>>>
> >>>> El mar., 11 dic. 2018 a las 21:24, Alex Harui
> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
> >>>> escribió:
> >>>>
> >>>>> Thinking about it more, -js-dynamic-access probably won't help. We
> don't
> >>>>> want to compile our SWCs with that option on and thus turn off
> minification
> >>>>> of these field names always if we can help it.
> >>>>>
> >>>>> Even a directive per occurrence won't help either. Whether a field
> name
> >>>>> is renamed is still dependent on what other code is in the
> compilation.
> >>>>>
> >>>>> The problem is better described as trying to find a way to control
> what
> >>>>> field names get renamed in more than one compilation, given that
> there is
> >>>>> pre-transpiled code that allows renaming. When building modules, we
> >>>>> already require using Closure Compiler options that output the
> renaming
> >>>>> maps of the main app so that UIBase is given the same short name in
> all
> >>>>> minifications. But there is no way to dictate that for field names
> as far
> >>>>> as I can tell.
> >>>>>
> >>>>> -Alex
> >>>>>
> >>>>> On 12/11/18, 11:32 AM, "Harbs" <harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com>> wrote:
> >>>>>
> >>>>> I vote for A.
> >>>>>
> >>>>> We can also do B which would require manually changing all access to
> >>>>> brackets and quote all names in object literals.
> >>>>>
> >>>>> I might be nice to add some comment decorations to enable/disable
> >>>>> -js-dynamic-access on a case-by-case basis, but I think it’s
> reasonable to
> >>>>> have a global on/off requirement. I’m already doing this for a
> library I
> >>>>> wrote which has a lot of dynamic data structures which does not
> survive
> >>>>> minification and the results are fine.
> >>>>>
> >>>>> My $0.02,
> >>>>> Harbs
> >>>>>
> >>>>>> On Dec 11, 2018, at 8:47 PM, Alex Harui <aharui@adobe.com.INVALID
> <ma...@adobe.com.INVALID>>
> >>>>> wrote:
> >>>>>>
> >>>>>> IMO, some folks will want to rely on minification of object field
> >>>>> names so save space. I think -js-dynamic-access blocks minification.
> >>>>>>
> >>>>>> So, to try to pose the problem another way, you can rely on
> >>>>> minification object field names if you are building a single-js-file
> app,
> >>>>> but as soon as you start using modules, things may break. So what
> should
> >>>>> we tell folks?
> >>>>>>
> >>>>>> A) if you use modules you must turn off minification in objects with
> >>>>> -js-dynamic-access
> >>>>>> B) here are some ways to hack your code so you can still rely on
> >>>>> minification
> >>>>>> C) something else?
> >>>>>>
> >>>>>> We can manually rename fields in ROYALE_CLASS_INFO and other
> >>>>> structures to make our code less readable in debug mode but save
> space in
> >>>>> release mode, but that does not solve the general case problem.
> Folks may
> >>>>> have other objects in their apps and modules that work until you add
> some
> >>>>> code to one of the projects that changes which object fields get
> renamed.
> >>>>>>
> >>>>>> -Alex
> >>>>>>
> >>>>>> On 12/11/18, 9:31 AM, "Harbs" <harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com>> wrote:
> >>>>>>
> >>>>>> I’m not following why this is the same point.
> >>>>>>
> >>>>>> I’m using -js-dynamic-access-unknown-members=true to handle this
> >>>>> kind of problem. It works flawlessly…
> >>>>>>
> >>>>>> I’d personally argue that true should be the default, but whether
> >>>>> the default is true or not, we do have an option to deal with these
> kinds
> >>>>> of data structures.
> >>>>>>
> >>>>>>> On Dec 11, 2018, at 6:39 PM, Alex Harui <aharui@adobe.com.INVALID
> <ma...@adobe.com.INVALID>>
> >>>>> wrote:
> >>>>>>>
> >>>>>>> Yes, we can use our own short names in code we generate, but that's
> >>>>> not really the point.
> >>>>>>>
> >>>>>>> The point is that any plain object field can be renamed based on
> >>>>> other code in the compile. So if you just have:
> >>>>>>>
> >>>>>>> Var obj:Object = { harbs: 1};
> >>>>>>> Public static function foo()
> >>>>>>> {
> >>>>>>> Trace(obj.harbs);
> >>>>>>> }
> >>>>>>>
> >>>>>>> Use of foo() in one compile may result in harbs being renamed, and
> >>>>> another wouldn't. And that poses a problem when data structures are
> shared
> >>>>> between compiled outputs.
> >>>>>>>
> >>>>>>> This is a natural way to write AS, but the JS results when minified
> >>>>> and shared between app and modules can fail. So what restrictions
> should
> >>>>> we place if any on how folks use plain objects?
> >>>>>>>
> >>>>>>> HTH,
> >>>>>>> -Alex
> >>>>>>>
> >>>>>>> On 12/11/18, 7:36 AM, "Harbs" <harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com>> wrote:
> >>>>>>>
> >>>>>>> I was about to make the same suggestion. We can use “I” for
> >>>>> interfaces, “c” for class, “k” for kind, “n” for names. etc.
> >>>>>>>
> >>>>>>>> On Dec 11, 2018, at 2:52 PM, Frost, Andrew
> <Andrew.Frost@Harman.com <ma...@Harman.com>>
> >>>>> wrote:
> >>>>>>>>
> >>>>>>>> Hi
> >>>>>>>>
> >>>>>>>> Not sure that I fully understand this but would a valid compromise
> >>>>> be something where the field name isn't renamed at all
> automatically, but
> >>>>> we just change it in the JS generation code to be "i" rather than
> >>>>> "interfaces", and update the Language is/as functions to work with
> this
> >>>>> property name? Not sure whether it would work and I don't know
> whether the
> >>>>> Reflection stuff would then need to change too, but if this is all
> in the
> >>>>> generated outputs and/or the framework's own code then it shouldn't
> be
> >>>>> something that the end user would bother about..
> >>>>>>>>
> >>>>>>>> thanks
> >>>>>>>>
> >>>>>>>> Andrew
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Alex Harui [mailto:aharui@adobe.com.INVALID <mailto:
> aharui@adobe.com.INVALID>]
> >>>>>>>> Sent: 11 December 2018 08:32
> >>>>>>>> To: dev@royale.apache.org <ma...@royale.apache.org>
> >>>>>>>> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules, Objects
> >>>>>>>>
> >>>>>>>> I spent some time today trying to get Tour De Flex to run in
> >>>>> production mode with the main app and modules being separately
> minified.
> >>>>>>>>
> >>>>>>>> I've fixed a few things here and there, but an interesting issue I
> >>>>> ran into has to do with the plain object we use in ROYALE_CLASS_INFO
> (and
> >>>>> will apply to other objects).
> >>>>>>>>
> >>>>>>>> The ROYALE_CLASS_INFO is generated on each class and has a "names"
> >>>>> property and an optional "interfaces" property. An example is:
> >>>>>>>>
> >>>>>>>>
> >>>>>
> org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO
> >>>>> = { names: [{ name: 'PanelModel', qName:
> >>>>> 'org.apache.royale.html.beads.models.PanelModel', kind: 'class' }],
> >>>>> interfaces: [org.apache.royale.core.IBead,
> >>>>> org.apache.royale.core.IPanelModel] };
> >>>>>>>>
> >>>>>>>> Because the field names are not quoted, then in most output, the
> >>>>> field name "interfaces" is renamed and all code referencing this
> field is
> >>>>> renamed as well. This is good because it means that you don't have
> to
> >>>>> download the word "interfaces" once per-class. Instead of 10
> characters, it
> >>>>> is usually one or two. 100 classes saves you about 900 bytes.
> >>>>>>>>
> >>>>>>>> However, it turns out that in Tour De Flex, the main app uses
> >>>>> Reflection and Reflection uses a quoted 'interfaces' string and
> thus, the
> >>>>> field name 'interfaces' in ROYALE_CLASS_INFO isn't renamed, but in
> most
> >>>>> modules "interfaces" is renamed since no other code in the module
> has a
> >>>>> quoted string for 'interfaces'. But that means that when a module
> loads,
> >>>>> the Language.is/as <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flanguage.is%2Fas&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=o%2FC8K1KRrYdkwLuQfkLG3tU2AlVRLGlaShPm37U5p8s%3D&reserved=0> won't work since classes
> in the main app are using
> >>>>> "interfaces" but the classes in the module are using some short name.
> >>>>>>>>
> >>>>>>>> One solution is to always quote that field in the compiler output
> >>>>> and Language is/as so it doesn't get renamed, but that means that
> field
> >>>>> will never get renamed and you lose saving those bytes.
> >>>>>>>>
> >>>>>>>> Another is let folks figure out their own workarounds, by adding
> >>>>> some code that will prevent the renaming in the modules.
> >>>>>>>>
> >>>>>>>> Other ideas are welcome. I'm done for tonight.
> >>>>>>>>
> >>>>>>>> Thoughts?
> >>>>>>>> -Alex
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Carlos Rovira
> >>>>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=MnCmCfYt2uepmueMxwDcMFE0Ah60sJxFa7Kg2wBTa00%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=MnCmCfYt2uepmueMxwDcMFE0Ah60sJxFa7Kg2wBTa00%3D&reserved=0
> ><
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=MnCmCfYt2uepmueMxwDcMFE0Ah60sJxFa7Kg2wBTa00%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=MnCmCfYt2uepmueMxwDcMFE0Ah60sJxFa7Kg2wBTa00%3D&reserved=0
> >>
>
>
--
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=eT5WhToYF5NCxjWsGbIWaLx86wBOUDg%2B%2BCjgct9XJr4%3D&reserved=0>
Carlos Rovira
Presidente Ejecutivo
M: +34 607 22 60 05
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=eT5WhToYF5NCxjWsGbIWaLx86wBOUDg%2B%2BCjgct9XJr4%3D&reserved=0
Conócenos en 1 minuto! <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favant2.es%2F%23video&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=HCsi5N6f87s7jX04eVfmVGT0J1IlGJ823VaKDSxHCbo%3D&reserved=0>
AVISO LEGAL: La información contenida en este correo electrónico, y en su
caso en los documentos adjuntos, es información privilegiada para uso
exclusivo de la persona y/o personas a las que va dirigido. No está
permitido el acceso a este mensaje a cualquier otra persona distinta a los
indicados. Si Usted no es uno de los destinatarios, cualquier duplicación,
reproducción, distribución, así como cualquier uso de la información
contenida en él o cualquiera otra acción u omisión tomada en relación con
el mismo, está prohibida y puede ser ilegal. En dicho caso, por favor,
notifíquelo al remitente y proceda a la eliminación de este correo
electrónico, así como de sus adjuntos si los hubiere. En cumplimiento de la
legislación española vigente en materia de protección de datos de carácter
personal y del RGPD 679/2016 le informamos que sus datos están siendo
objeto de tratamiento por parte de CODEOSCOPIC S.A. con CIFA85677342, con
la finalidad del mantenimiento y gestión de relaciones comerciales y
administrativas. La base jurídica del tratamiento es el interés legítimo de
la empresa. No se prevén cesiones de sus datos, salvo que exista una
obligación legal. Para ejercitar sus derechos puede dirigirse a CODEOSCOPIC
S.A., domiciliada enPaseo de la Habana, 9-11, 28036 de Madrid (MADRID), o
bien por email adpd@codeoscopic.com, con el fin de ejercer sus derechos de
acceso, rectificación, supresión (derecho al olvido), limitación de
tratamiento, portabilidad de los datos, oposición, y a no ser objeto de
decisiones automatizadas, indicando como Asunto: “Derechos Ley Protección
de Datos”, y adjuntando fotocopia de su DNI. Delegado de protección de
datos:dpd@codeoscopic.com
Re: ROYALE_CLASS_INFO, renaming, modules, Objects
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Harb,
That seems ok, but moreover...why don't we have a class definition instead
a plain object, somethings like RoyaleClassInfo.as?
Since Royale tries to enforce typing, I think using a plain object for
royale class info, doesn't seems the most proper way to me
thanks
El mié., 12 dic. 2018 a las 11:23, Harbs (<ha...@gmail.com>) escribió:
> Right, but I thought we already suggested single character names for the
> ROYALE_CLASS_INFO object.
>
> To take one example:
> org.apache.royale.html.supportClasses.Viewport.prototype.ROYALE_CLASS_INFO
> = { names: [{ name: 'Viewport', qName:
> 'org.apache.royale.html.supportClasses.Viewport', kind: 'class' }],
> interfaces: [org.apache.royale.core.IBead,
> org.apache.royale.core.IViewport] };
>
> That would become:
> org.apache.royale.html.supportClasses.Viewport.prototype.ROYALE_CLASS_INFO
> = { n: [{ n: 'Viewport', q:
> 'org.apache.royale.html.supportClasses.Viewport', k: 'class' }], i:
> [org.apache.royale.core.IBead, org.apache.royale.core.IViewport] };
>
> I’m pretty sure that’s enough to prevent renaming (because the closure
> compiler does not rename single character variable names). If I’m wrong, we
> could always output something like this:
>
> org.apache.royale.html.supportClasses.Viewport.prototype.ROYALE_CLASS_INFO
> = { 'n': [{ 'n': 'Viewport', 'q':
> 'org.apache.royale.html.supportClasses.Viewport', 'k': 'class' }], 'i':
> [org.apache.royale.core.IBead, org.apache.royale.core.IViewport] };
>
> Am I missing something?
> Harbs
>
> > On Dec 12, 2018, at 12:32 AM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >
> > ROYALE_CLASS_INFO is a dynamic object. There is no class definition for
> it, which means that its field names can be renamed.
> >
> > The whole point of modules is to load classes that aren't in the main
> app so that the main app loads faster. So, if you have
> >
> > MainApp.mxml
> > <mx:Application>
> > <mx:ModuleLoader url="MyModule" />
> > </mx:Application>
> >
> > MyModule.mxml
> > <mx:Module>
> > </mx:Module>
> >
> > The Language.is <http://language.is/> function linked into Main app
> might be checking for ROYALE_CLASS_INFO.interfaces and Application class
> will have a ROYALE_CLASS_INFO.interfaces property. But Module might have
> ROYALE_CLASS_INFO.i instead of interfaces. And thus Language.is <
> http://language.is/> will not work on classes in the module. It depends
> on what other code is in the main app. It appears that use of
> Reflection.SWC's TypeDefinition in the main app tells the minifier to not
> minify the "interfaces" property. Which means that any code an app
> developer might add to the app could change the minification of
> ROYALE_CLASS_INFO, or any other dynamic object.
> >
> > I'm trying to figure out why the minifier thinks the use of "interfaces"
> in TypeDefinition matters but other attempts I've tried to force the
> minifier to not rename "interfaces" in the module have not worked.
> >
> > HTH,
> > -Alex
> >
> > On 12/11/18, 2:19 PM, "Harbs" <harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com>> wrote:
> >
> > I’m still not getting the connection to ROYALE_CLASS_INFO.
> >
> > Can you explain to me in pseudo-code the problem with that? Why does
> a dynamic object have ROYALE_CLASS_INFO at all?
> >
> >> On Dec 12, 2018, at 12:16 AM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >>
> >> I'm not sure why you think it is theoretical. For sure, in TDF, the
> module is not loading because ROYALE_CLASS_INFO is minified differently in
> the main app than the module. Any dynamic objects shared across
> compilations are at risk of being renamed differently. I'm chasing down a
> way to control it.
> >>
> >> We do have control over the names of classes and properties to
> guarantee they are the same in the app and module. It is just these
> dynamic object keys that we don't yet have control over.
> >>
> >> We do have the option of defining a class for ROYALE_CLASS_INFO, but
> then it will never minify. I like the fact that it can minify without us
> having to use shortnames. It makes our debug code more readable and
> doesn't waste space in small apps. Adding a class definition for
> ROYALE_CLASS_INFO would further add overhead to small apps.
> >>
> >> My 2 cents,
> >> -Alex
> >>
> >> On 12/11/18, 2:06 PM, "Harbs" <harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com> <mailto:harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com>>> wrote:
> >>
> >> In fact, in looking through the framework code so far, the only place
> I’ve found variable names not quoted (in JS compatible code) so far was in
> CSSUtils where we have a colorMap. I’m pretty sure the colorMap will not
> work after minification because the color names will not match…
> >>
> >>> On Dec 12, 2018, at 12:01 AM, Harbs <harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com>> wrote:
> >>>
> >>> Hi Carlos,
> >>>
> >>> We’re only discussing dynamic objects. How many of those do you have
> in your applications? I doubt there’s much difference in performance due to
> minification of dynamic objects.
> >>>
> >>> In *all* our framework code we have dynamic object instantiation in
> 435 places including TLF, Spark and MX classes. Without those packages, I’m
> estimating it’s a small fraction of that and probably most of the dynamic
> objects are hash maps where they don’t benefit from minification anyway.
> >>>
> >>> The vast majority of the cases where you’re using dynamic objects in
> production code you don’t want the names minified either (i.e. API calls
> and uses of JSON).
> >>>
> >>> I think that most of this discussion is more theoretical than
> practical considerations.
> >>>
> >>> My $0.02,
> >>> Harbs
> >>>
> >>>> On Dec 11, 2018, at 11:26 PM, Carlos Rovira <carlosrovira@apache.org
> <ma...@apache.org>> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> I'm still not using modules. I left that for now until we complete the
> >>>> first phase in our project, but will be using (hopefully) around
> February.
> >>>>
> >>>> So right now we're only using minification, that seems not only to
> reduce
> >>>> the size of the build, but release mode performs faster, and I think
> is
> >>>> due, in part, to minify.
> >>>>
> >>>> So, IMHO, as a user, I don't like A). Can't think of a solution,
> since is
> >>>> not my zone of expertise, and sure you guys found a good solution
> after
> >>>> all. Just want to say that as a user, is importante both things: have
> >>>> modules (and hope we could link as well with routing like people do in
> >>>> other current techs like React and Angular to get a powerful solution
> for
> >>>> SPAs) and have minification, since IMO, the resultant js-release
> build has
> >>>> many, many advantages, not only in performance and size but as well in
> >>>> obfuscation, and for me is like our "binary output code".
> >>>>
> >>>> Sorry to not be able to give any suggestion, but maybe as well an
> opinion
> >>>> of use is as well valuable.
> >>>>
> >>>> just my 2
> >>>>
> >>>>
> >>>> El mar., 11 dic. 2018 a las 21:24, Alex Harui
> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
> >>>> escribió:
> >>>>
> >>>>> Thinking about it more, -js-dynamic-access probably won't help. We
> don't
> >>>>> want to compile our SWCs with that option on and thus turn off
> minification
> >>>>> of these field names always if we can help it.
> >>>>>
> >>>>> Even a directive per occurrence won't help either. Whether a field
> name
> >>>>> is renamed is still dependent on what other code is in the
> compilation.
> >>>>>
> >>>>> The problem is better described as trying to find a way to control
> what
> >>>>> field names get renamed in more than one compilation, given that
> there is
> >>>>> pre-transpiled code that allows renaming. When building modules, we
> >>>>> already require using Closure Compiler options that output the
> renaming
> >>>>> maps of the main app so that UIBase is given the same short name in
> all
> >>>>> minifications. But there is no way to dictate that for field names
> as far
> >>>>> as I can tell.
> >>>>>
> >>>>> -Alex
> >>>>>
> >>>>> On 12/11/18, 11:32 AM, "Harbs" <harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com>> wrote:
> >>>>>
> >>>>> I vote for A.
> >>>>>
> >>>>> We can also do B which would require manually changing all access to
> >>>>> brackets and quote all names in object literals.
> >>>>>
> >>>>> I might be nice to add some comment decorations to enable/disable
> >>>>> -js-dynamic-access on a case-by-case basis, but I think it’s
> reasonable to
> >>>>> have a global on/off requirement. I’m already doing this for a
> library I
> >>>>> wrote which has a lot of dynamic data structures which does not
> survive
> >>>>> minification and the results are fine.
> >>>>>
> >>>>> My $0.02,
> >>>>> Harbs
> >>>>>
> >>>>>> On Dec 11, 2018, at 8:47 PM, Alex Harui <aharui@adobe.com.INVALID
> <ma...@adobe.com.INVALID>>
> >>>>> wrote:
> >>>>>>
> >>>>>> IMO, some folks will want to rely on minification of object field
> >>>>> names so save space. I think -js-dynamic-access blocks minification.
> >>>>>>
> >>>>>> So, to try to pose the problem another way, you can rely on
> >>>>> minification object field names if you are building a single-js-file
> app,
> >>>>> but as soon as you start using modules, things may break. So what
> should
> >>>>> we tell folks?
> >>>>>>
> >>>>>> A) if you use modules you must turn off minification in objects with
> >>>>> -js-dynamic-access
> >>>>>> B) here are some ways to hack your code so you can still rely on
> >>>>> minification
> >>>>>> C) something else?
> >>>>>>
> >>>>>> We can manually rename fields in ROYALE_CLASS_INFO and other
> >>>>> structures to make our code less readable in debug mode but save
> space in
> >>>>> release mode, but that does not solve the general case problem.
> Folks may
> >>>>> have other objects in their apps and modules that work until you add
> some
> >>>>> code to one of the projects that changes which object fields get
> renamed.
> >>>>>>
> >>>>>> -Alex
> >>>>>>
> >>>>>> On 12/11/18, 9:31 AM, "Harbs" <harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com>> wrote:
> >>>>>>
> >>>>>> I’m not following why this is the same point.
> >>>>>>
> >>>>>> I’m using -js-dynamic-access-unknown-members=true to handle this
> >>>>> kind of problem. It works flawlessly…
> >>>>>>
> >>>>>> I’d personally argue that true should be the default, but whether
> >>>>> the default is true or not, we do have an option to deal with these
> kinds
> >>>>> of data structures.
> >>>>>>
> >>>>>>> On Dec 11, 2018, at 6:39 PM, Alex Harui <aharui@adobe.com.INVALID
> <ma...@adobe.com.INVALID>>
> >>>>> wrote:
> >>>>>>>
> >>>>>>> Yes, we can use our own short names in code we generate, but that's
> >>>>> not really the point.
> >>>>>>>
> >>>>>>> The point is that any plain object field can be renamed based on
> >>>>> other code in the compile. So if you just have:
> >>>>>>>
> >>>>>>> Var obj:Object = { harbs: 1};
> >>>>>>> Public static function foo()
> >>>>>>> {
> >>>>>>> Trace(obj.harbs);
> >>>>>>> }
> >>>>>>>
> >>>>>>> Use of foo() in one compile may result in harbs being renamed, and
> >>>>> another wouldn't. And that poses a problem when data structures are
> shared
> >>>>> between compiled outputs.
> >>>>>>>
> >>>>>>> This is a natural way to write AS, but the JS results when minified
> >>>>> and shared between app and modules can fail. So what restrictions
> should
> >>>>> we place if any on how folks use plain objects?
> >>>>>>>
> >>>>>>> HTH,
> >>>>>>> -Alex
> >>>>>>>
> >>>>>>> On 12/11/18, 7:36 AM, "Harbs" <harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com>> wrote:
> >>>>>>>
> >>>>>>> I was about to make the same suggestion. We can use “I” for
> >>>>> interfaces, “c” for class, “k” for kind, “n” for names. etc.
> >>>>>>>
> >>>>>>>> On Dec 11, 2018, at 2:52 PM, Frost, Andrew
> <Andrew.Frost@Harman.com <ma...@Harman.com>>
> >>>>> wrote:
> >>>>>>>>
> >>>>>>>> Hi
> >>>>>>>>
> >>>>>>>> Not sure that I fully understand this but would a valid compromise
> >>>>> be something where the field name isn't renamed at all
> automatically, but
> >>>>> we just change it in the JS generation code to be "i" rather than
> >>>>> "interfaces", and update the Language is/as functions to work with
> this
> >>>>> property name? Not sure whether it would work and I don't know
> whether the
> >>>>> Reflection stuff would then need to change too, but if this is all
> in the
> >>>>> generated outputs and/or the framework's own code then it shouldn't
> be
> >>>>> something that the end user would bother about..
> >>>>>>>>
> >>>>>>>> thanks
> >>>>>>>>
> >>>>>>>> Andrew
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Alex Harui [mailto:aharui@adobe.com.INVALID <mailto:
> aharui@adobe.com.INVALID>]
> >>>>>>>> Sent: 11 December 2018 08:32
> >>>>>>>> To: dev@royale.apache.org <ma...@royale.apache.org>
> >>>>>>>> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules, Objects
> >>>>>>>>
> >>>>>>>> I spent some time today trying to get Tour De Flex to run in
> >>>>> production mode with the main app and modules being separately
> minified.
> >>>>>>>>
> >>>>>>>> I've fixed a few things here and there, but an interesting issue I
> >>>>> ran into has to do with the plain object we use in ROYALE_CLASS_INFO
> (and
> >>>>> will apply to other objects).
> >>>>>>>>
> >>>>>>>> The ROYALE_CLASS_INFO is generated on each class and has a "names"
> >>>>> property and an optional "interfaces" property. An example is:
> >>>>>>>>
> >>>>>>>>
> >>>>>
> org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO
> >>>>> = { names: [{ name: 'PanelModel', qName:
> >>>>> 'org.apache.royale.html.beads.models.PanelModel', kind: 'class' }],
> >>>>> interfaces: [org.apache.royale.core.IBead,
> >>>>> org.apache.royale.core.IPanelModel] };
> >>>>>>>>
> >>>>>>>> Because the field names are not quoted, then in most output, the
> >>>>> field name "interfaces" is renamed and all code referencing this
> field is
> >>>>> renamed as well. This is good because it means that you don't have
> to
> >>>>> download the word "interfaces" once per-class. Instead of 10
> characters, it
> >>>>> is usually one or two. 100 classes saves you about 900 bytes.
> >>>>>>>>
> >>>>>>>> However, it turns out that in Tour De Flex, the main app uses
> >>>>> Reflection and Reflection uses a quoted 'interfaces' string and
> thus, the
> >>>>> field name 'interfaces' in ROYALE_CLASS_INFO isn't renamed, but in
> most
> >>>>> modules "interfaces" is renamed since no other code in the module
> has a
> >>>>> quoted string for 'interfaces'. But that means that when a module
> loads,
> >>>>> the Language.is/as <http://language.is/as> won't work since classes
> in the main app are using
> >>>>> "interfaces" but the classes in the module are using some short name.
> >>>>>>>>
> >>>>>>>> One solution is to always quote that field in the compiler output
> >>>>> and Language is/as so it doesn't get renamed, but that means that
> field
> >>>>> will never get renamed and you lose saving those bytes.
> >>>>>>>>
> >>>>>>>> Another is let folks figure out their own workarounds, by adding
> >>>>> some code that will prevent the renaming in the modules.
> >>>>>>>>
> >>>>>>>> Other ideas are welcome. I'm done for tonight.
> >>>>>>>>
> >>>>>>>> Thoughts?
> >>>>>>>> -Alex
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Carlos Rovira
> >>>>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2c36443f61b4436324ee08d65fb6a252%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636801635412696785&sdata=DwG2KMwX7oKIaag1NeuP%2BnNwPp4VD7amvdLaKmPQ7H8%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2c36443f61b4436324ee08d65fb6a252%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636801635412696785&sdata=DwG2KMwX7oKIaag1NeuP%2BnNwPp4VD7amvdLaKmPQ7H8%3D&reserved=0
> ><
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2c36443f61b4436324ee08d65fb6a252%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636801635412696785&sdata=DwG2KMwX7oKIaag1NeuP%2BnNwPp4VD7amvdLaKmPQ7H8%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2c36443f61b4436324ee08d65fb6a252%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636801635412696785&sdata=DwG2KMwX7oKIaag1NeuP%2BnNwPp4VD7amvdLaKmPQ7H8%3D&reserved=0
> >>
>
>
--
<http://www.codeoscopic.com>
Carlos Rovira
Presidente Ejecutivo
M: +34 607 22 60 05
http://www.codeoscopic.com
Conócenos en 1 minuto! <https://avant2.es/#video>
AVISO LEGAL: La información contenida en este correo electrónico, y en su
caso en los documentos adjuntos, es información privilegiada para uso
exclusivo de la persona y/o personas a las que va dirigido. No está
permitido el acceso a este mensaje a cualquier otra persona distinta a los
indicados. Si Usted no es uno de los destinatarios, cualquier duplicación,
reproducción, distribución, así como cualquier uso de la información
contenida en él o cualquiera otra acción u omisión tomada en relación con
el mismo, está prohibida y puede ser ilegal. En dicho caso, por favor,
notifíquelo al remitente y proceda a la eliminación de este correo
electrónico, así como de sus adjuntos si los hubiere. En cumplimiento de la
legislación española vigente en materia de protección de datos de carácter
personal y del RGPD 679/2016 le informamos que sus datos están siendo
objeto de tratamiento por parte de CODEOSCOPIC S.A. con CIFA85677342, con
la finalidad del mantenimiento y gestión de relaciones comerciales y
administrativas. La base jurídica del tratamiento es el interés legítimo de
la empresa. No se prevén cesiones de sus datos, salvo que exista una
obligación legal. Para ejercitar sus derechos puede dirigirse a CODEOSCOPIC
S.A., domiciliada enPaseo de la Habana, 9-11, 28036 de Madrid (MADRID), o
bien por email adpd@codeoscopic.com, con el fin de ejercer sus derechos de
acceso, rectificación, supresión (derecho al olvido), limitación de
tratamiento, portabilidad de los datos, oposición, y a no ser objeto de
decisiones automatizadas, indicando como Asunto: “Derechos Ley Protección
de Datos”, y adjuntando fotocopia de su DNI. Delegado de protección de
datos:dpd@codeoscopic.com
Re: ROYALE_CLASS_INFO, renaming, modules, Objects
Posted by Harbs <ha...@gmail.com>.
Right, but I thought we already suggested single character names for the ROYALE_CLASS_INFO object.
To take one example:
org.apache.royale.html.supportClasses.Viewport.prototype.ROYALE_CLASS_INFO = { names: [{ name: 'Viewport', qName: 'org.apache.royale.html.supportClasses.Viewport', kind: 'class' }], interfaces: [org.apache.royale.core.IBead, org.apache.royale.core.IViewport] };
That would become:
org.apache.royale.html.supportClasses.Viewport.prototype.ROYALE_CLASS_INFO = { n: [{ n: 'Viewport', q: 'org.apache.royale.html.supportClasses.Viewport', k: 'class' }], i: [org.apache.royale.core.IBead, org.apache.royale.core.IViewport] };
I’m pretty sure that’s enough to prevent renaming (because the closure compiler does not rename single character variable names). If I’m wrong, we could always output something like this:
org.apache.royale.html.supportClasses.Viewport.prototype.ROYALE_CLASS_INFO = { 'n': [{ 'n': 'Viewport', 'q': 'org.apache.royale.html.supportClasses.Viewport', 'k': 'class' }], 'i': [org.apache.royale.core.IBead, org.apache.royale.core.IViewport] };
Am I missing something?
Harbs
> On Dec 12, 2018, at 12:32 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> ROYALE_CLASS_INFO is a dynamic object. There is no class definition for it, which means that its field names can be renamed.
>
> The whole point of modules is to load classes that aren't in the main app so that the main app loads faster. So, if you have
>
> MainApp.mxml
> <mx:Application>
> <mx:ModuleLoader url="MyModule" />
> </mx:Application>
>
> MyModule.mxml
> <mx:Module>
> </mx:Module>
>
> The Language.is <http://language.is/> function linked into Main app might be checking for ROYALE_CLASS_INFO.interfaces and Application class will have a ROYALE_CLASS_INFO.interfaces property. But Module might have ROYALE_CLASS_INFO.i instead of interfaces. And thus Language.is <http://language.is/> will not work on classes in the module. It depends on what other code is in the main app. It appears that use of Reflection.SWC's TypeDefinition in the main app tells the minifier to not minify the "interfaces" property. Which means that any code an app developer might add to the app could change the minification of ROYALE_CLASS_INFO, or any other dynamic object.
>
> I'm trying to figure out why the minifier thinks the use of "interfaces" in TypeDefinition matters but other attempts I've tried to force the minifier to not rename "interfaces" in the module have not worked.
>
> HTH,
> -Alex
>
> On 12/11/18, 2:19 PM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>
> I’m still not getting the connection to ROYALE_CLASS_INFO.
>
> Can you explain to me in pseudo-code the problem with that? Why does a dynamic object have ROYALE_CLASS_INFO at all?
>
>> On Dec 12, 2018, at 12:16 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> I'm not sure why you think it is theoretical. For sure, in TDF, the module is not loading because ROYALE_CLASS_INFO is minified differently in the main app than the module. Any dynamic objects shared across compilations are at risk of being renamed differently. I'm chasing down a way to control it.
>>
>> We do have control over the names of classes and properties to guarantee they are the same in the app and module. It is just these dynamic object keys that we don't yet have control over.
>>
>> We do have the option of defining a class for ROYALE_CLASS_INFO, but then it will never minify. I like the fact that it can minify without us having to use shortnames. It makes our debug code more readable and doesn't waste space in small apps. Adding a class definition for ROYALE_CLASS_INFO would further add overhead to small apps.
>>
>> My 2 cents,
>> -Alex
>>
>> On 12/11/18, 2:06 PM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>> wrote:
>>
>> In fact, in looking through the framework code so far, the only place I’ve found variable names not quoted (in JS compatible code) so far was in CSSUtils where we have a colorMap. I’m pretty sure the colorMap will not work after minification because the color names will not match…
>>
>>> On Dec 12, 2018, at 12:01 AM, Harbs <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> Hi Carlos,
>>>
>>> We’re only discussing dynamic objects. How many of those do you have in your applications? I doubt there’s much difference in performance due to minification of dynamic objects.
>>>
>>> In *all* our framework code we have dynamic object instantiation in 435 places including TLF, Spark and MX classes. Without those packages, I’m estimating it’s a small fraction of that and probably most of the dynamic objects are hash maps where they don’t benefit from minification anyway.
>>>
>>> The vast majority of the cases where you’re using dynamic objects in production code you don’t want the names minified either (i.e. API calls and uses of JSON).
>>>
>>> I think that most of this discussion is more theoretical than practical considerations.
>>>
>>> My $0.02,
>>> Harbs
>>>
>>>> On Dec 11, 2018, at 11:26 PM, Carlos Rovira <carlosrovira@apache.org <ma...@apache.org>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I'm still not using modules. I left that for now until we complete the
>>>> first phase in our project, but will be using (hopefully) around February.
>>>>
>>>> So right now we're only using minification, that seems not only to reduce
>>>> the size of the build, but release mode performs faster, and I think is
>>>> due, in part, to minify.
>>>>
>>>> So, IMHO, as a user, I don't like A). Can't think of a solution, since is
>>>> not my zone of expertise, and sure you guys found a good solution after
>>>> all. Just want to say that as a user, is importante both things: have
>>>> modules (and hope we could link as well with routing like people do in
>>>> other current techs like React and Angular to get a powerful solution for
>>>> SPAs) and have minification, since IMO, the resultant js-release build has
>>>> many, many advantages, not only in performance and size but as well in
>>>> obfuscation, and for me is like our "binary output code".
>>>>
>>>> Sorry to not be able to give any suggestion, but maybe as well an opinion
>>>> of use is as well valuable.
>>>>
>>>> just my 2
>>>>
>>>>
>>>> El mar., 11 dic. 2018 a las 21:24, Alex Harui (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>>>> escribió:
>>>>
>>>>> Thinking about it more, -js-dynamic-access probably won't help. We don't
>>>>> want to compile our SWCs with that option on and thus turn off minification
>>>>> of these field names always if we can help it.
>>>>>
>>>>> Even a directive per occurrence won't help either. Whether a field name
>>>>> is renamed is still dependent on what other code is in the compilation.
>>>>>
>>>>> The problem is better described as trying to find a way to control what
>>>>> field names get renamed in more than one compilation, given that there is
>>>>> pre-transpiled code that allows renaming. When building modules, we
>>>>> already require using Closure Compiler options that output the renaming
>>>>> maps of the main app so that UIBase is given the same short name in all
>>>>> minifications. But there is no way to dictate that for field names as far
>>>>> as I can tell.
>>>>>
>>>>> -Alex
>>>>>
>>>>> On 12/11/18, 11:32 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>>>>
>>>>> I vote for A.
>>>>>
>>>>> We can also do B which would require manually changing all access to
>>>>> brackets and quote all names in object literals.
>>>>>
>>>>> I might be nice to add some comment decorations to enable/disable
>>>>> -js-dynamic-access on a case-by-case basis, but I think it’s reasonable to
>>>>> have a global on/off requirement. I’m already doing this for a library I
>>>>> wrote which has a lot of dynamic data structures which does not survive
>>>>> minification and the results are fine.
>>>>>
>>>>> My $0.02,
>>>>> Harbs
>>>>>
>>>>>> On Dec 11, 2018, at 8:47 PM, Alex Harui <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>>
>>>>> wrote:
>>>>>>
>>>>>> IMO, some folks will want to rely on minification of object field
>>>>> names so save space. I think -js-dynamic-access blocks minification.
>>>>>>
>>>>>> So, to try to pose the problem another way, you can rely on
>>>>> minification object field names if you are building a single-js-file app,
>>>>> but as soon as you start using modules, things may break. So what should
>>>>> we tell folks?
>>>>>>
>>>>>> A) if you use modules you must turn off minification in objects with
>>>>> -js-dynamic-access
>>>>>> B) here are some ways to hack your code so you can still rely on
>>>>> minification
>>>>>> C) something else?
>>>>>>
>>>>>> We can manually rename fields in ROYALE_CLASS_INFO and other
>>>>> structures to make our code less readable in debug mode but save space in
>>>>> release mode, but that does not solve the general case problem. Folks may
>>>>> have other objects in their apps and modules that work until you add some
>>>>> code to one of the projects that changes which object fields get renamed.
>>>>>>
>>>>>> -Alex
>>>>>>
>>>>>> On 12/11/18, 9:31 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>>>>>
>>>>>> I’m not following why this is the same point.
>>>>>>
>>>>>> I’m using -js-dynamic-access-unknown-members=true to handle this
>>>>> kind of problem. It works flawlessly…
>>>>>>
>>>>>> I’d personally argue that true should be the default, but whether
>>>>> the default is true or not, we do have an option to deal with these kinds
>>>>> of data structures.
>>>>>>
>>>>>>> On Dec 11, 2018, at 6:39 PM, Alex Harui <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>>
>>>>> wrote:
>>>>>>>
>>>>>>> Yes, we can use our own short names in code we generate, but that's
>>>>> not really the point.
>>>>>>>
>>>>>>> The point is that any plain object field can be renamed based on
>>>>> other code in the compile. So if you just have:
>>>>>>>
>>>>>>> Var obj:Object = { harbs: 1};
>>>>>>> Public static function foo()
>>>>>>> {
>>>>>>> Trace(obj.harbs);
>>>>>>> }
>>>>>>>
>>>>>>> Use of foo() in one compile may result in harbs being renamed, and
>>>>> another wouldn't. And that poses a problem when data structures are shared
>>>>> between compiled outputs.
>>>>>>>
>>>>>>> This is a natural way to write AS, but the JS results when minified
>>>>> and shared between app and modules can fail. So what restrictions should
>>>>> we place if any on how folks use plain objects?
>>>>>>>
>>>>>>> HTH,
>>>>>>> -Alex
>>>>>>>
>>>>>>> On 12/11/18, 7:36 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>
>>>>>>> I was about to make the same suggestion. We can use “I” for
>>>>> interfaces, “c” for class, “k” for kind, “n” for names. etc.
>>>>>>>
>>>>>>>> On Dec 11, 2018, at 2:52 PM, Frost, Andrew <Andrew.Frost@Harman.com <ma...@Harman.com>>
>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> Not sure that I fully understand this but would a valid compromise
>>>>> be something where the field name isn't renamed at all automatically, but
>>>>> we just change it in the JS generation code to be "i" rather than
>>>>> "interfaces", and update the Language is/as functions to work with this
>>>>> property name? Not sure whether it would work and I don't know whether the
>>>>> Reflection stuff would then need to change too, but if this is all in the
>>>>> generated outputs and/or the framework's own code then it shouldn't be
>>>>> something that the end user would bother about..
>>>>>>>>
>>>>>>>> thanks
>>>>>>>>
>>>>>>>> Andrew
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Alex Harui [mailto:aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>]
>>>>>>>> Sent: 11 December 2018 08:32
>>>>>>>> To: dev@royale.apache.org <ma...@royale.apache.org>
>>>>>>>> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules, Objects
>>>>>>>>
>>>>>>>> I spent some time today trying to get Tour De Flex to run in
>>>>> production mode with the main app and modules being separately minified.
>>>>>>>>
>>>>>>>> I've fixed a few things here and there, but an interesting issue I
>>>>> ran into has to do with the plain object we use in ROYALE_CLASS_INFO (and
>>>>> will apply to other objects).
>>>>>>>>
>>>>>>>> The ROYALE_CLASS_INFO is generated on each class and has a "names"
>>>>> property and an optional "interfaces" property. An example is:
>>>>>>>>
>>>>>>>>
>>>>> org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO
>>>>> = { names: [{ name: 'PanelModel', qName:
>>>>> 'org.apache.royale.html.beads.models.PanelModel', kind: 'class' }],
>>>>> interfaces: [org.apache.royale.core.IBead,
>>>>> org.apache.royale.core.IPanelModel] };
>>>>>>>>
>>>>>>>> Because the field names are not quoted, then in most output, the
>>>>> field name "interfaces" is renamed and all code referencing this field is
>>>>> renamed as well. This is good because it means that you don't have to
>>>>> download the word "interfaces" once per-class. Instead of 10 characters, it
>>>>> is usually one or two. 100 classes saves you about 900 bytes.
>>>>>>>>
>>>>>>>> However, it turns out that in Tour De Flex, the main app uses
>>>>> Reflection and Reflection uses a quoted 'interfaces' string and thus, the
>>>>> field name 'interfaces' in ROYALE_CLASS_INFO isn't renamed, but in most
>>>>> modules "interfaces" is renamed since no other code in the module has a
>>>>> quoted string for 'interfaces'. But that means that when a module loads,
>>>>> the Language.is/as <http://language.is/as> won't work since classes in the main app are using
>>>>> "interfaces" but the classes in the module are using some short name.
>>>>>>>>
>>>>>>>> One solution is to always quote that field in the compiler output
>>>>> and Language is/as so it doesn't get renamed, but that means that field
>>>>> will never get renamed and you lose saving those bytes.
>>>>>>>>
>>>>>>>> Another is let folks figure out their own workarounds, by adding
>>>>> some code that will prevent the renaming in the modules.
>>>>>>>>
>>>>>>>> Other ideas are welcome. I'm done for tonight.
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>> -Alex
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Carlos Rovira
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2c36443f61b4436324ee08d65fb6a252%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636801635412696785&sdata=DwG2KMwX7oKIaag1NeuP%2BnNwPp4VD7amvdLaKmPQ7H8%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2c36443f61b4436324ee08d65fb6a252%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636801635412696785&sdata=DwG2KMwX7oKIaag1NeuP%2BnNwPp4VD7amvdLaKmPQ7H8%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2c36443f61b4436324ee08d65fb6a252%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636801635412696785&sdata=DwG2KMwX7oKIaag1NeuP%2BnNwPp4VD7amvdLaKmPQ7H8%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2c36443f61b4436324ee08d65fb6a252%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636801635412696785&sdata=DwG2KMwX7oKIaag1NeuP%2BnNwPp4VD7amvdLaKmPQ7H8%3D&reserved=0>>
Re: ROYALE_CLASS_INFO, renaming, modules, Objects
Posted by Alex Harui <ah...@adobe.com.INVALID>.
ROYALE_CLASS_INFO is a dynamic object. There is no class definition for it, which means that its field names can be renamed.
The whole point of modules is to load classes that aren't in the main app so that the main app loads faster. So, if you have
MainApp.mxml
<mx:Application>
<mx:ModuleLoader url="MyModule" />
</mx:Application>
MyModule.mxml
<mx:Module>
</mx:Module>
The Language.is function linked into Main app might be checking for ROYALE_CLASS_INFO.interfaces and Application class will have a ROYALE_CLASS_INFO.interfaces property. But Module might have ROYALE_CLASS_INFO.i instead of interfaces. And thus Language.is will not work on classes in the module. It depends on what other code is in the main app. It appears that use of Reflection.SWC's TypeDefinition in the main app tells the minifier to not minify the "interfaces" property. Which means that any code an app developer might add to the app could change the minification of ROYALE_CLASS_INFO, or any other dynamic object.
I'm trying to figure out why the minifier thinks the use of "interfaces" in TypeDefinition matters but other attempts I've tried to force the minifier to not rename "interfaces" in the module have not worked.
HTH,
-Alex
On 12/11/18, 2:19 PM, "Harbs" <ha...@gmail.com> wrote:
I’m still not getting the connection to ROYALE_CLASS_INFO.
Can you explain to me in pseudo-code the problem with that? Why does a dynamic object have ROYALE_CLASS_INFO at all?
> On Dec 12, 2018, at 12:16 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> I'm not sure why you think it is theoretical. For sure, in TDF, the module is not loading because ROYALE_CLASS_INFO is minified differently in the main app than the module. Any dynamic objects shared across compilations are at risk of being renamed differently. I'm chasing down a way to control it.
>
> We do have control over the names of classes and properties to guarantee they are the same in the app and module. It is just these dynamic object keys that we don't yet have control over.
>
> We do have the option of defining a class for ROYALE_CLASS_INFO, but then it will never minify. I like the fact that it can minify without us having to use shortnames. It makes our debug code more readable and doesn't waste space in small apps. Adding a class definition for ROYALE_CLASS_INFO would further add overhead to small apps.
>
> My 2 cents,
> -Alex
>
> On 12/11/18, 2:06 PM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>
> In fact, in looking through the framework code so far, the only place I’ve found variable names not quoted (in JS compatible code) so far was in CSSUtils where we have a colorMap. I’m pretty sure the colorMap will not work after minification because the color names will not match…
>
>> On Dec 12, 2018, at 12:01 AM, Harbs <ha...@gmail.com> wrote:
>>
>> Hi Carlos,
>>
>> We’re only discussing dynamic objects. How many of those do you have in your applications? I doubt there’s much difference in performance due to minification of dynamic objects.
>>
>> In *all* our framework code we have dynamic object instantiation in 435 places including TLF, Spark and MX classes. Without those packages, I’m estimating it’s a small fraction of that and probably most of the dynamic objects are hash maps where they don’t benefit from minification anyway.
>>
>> The vast majority of the cases where you’re using dynamic objects in production code you don’t want the names minified either (i.e. API calls and uses of JSON).
>>
>> I think that most of this discussion is more theoretical than practical considerations.
>>
>> My $0.02,
>> Harbs
>>
>>> On Dec 11, 2018, at 11:26 PM, Carlos Rovira <ca...@apache.org> wrote:
>>>
>>> Hi,
>>>
>>> I'm still not using modules. I left that for now until we complete the
>>> first phase in our project, but will be using (hopefully) around February.
>>>
>>> So right now we're only using minification, that seems not only to reduce
>>> the size of the build, but release mode performs faster, and I think is
>>> due, in part, to minify.
>>>
>>> So, IMHO, as a user, I don't like A). Can't think of a solution, since is
>>> not my zone of expertise, and sure you guys found a good solution after
>>> all. Just want to say that as a user, is importante both things: have
>>> modules (and hope we could link as well with routing like people do in
>>> other current techs like React and Angular to get a powerful solution for
>>> SPAs) and have minification, since IMO, the resultant js-release build has
>>> many, many advantages, not only in performance and size but as well in
>>> obfuscation, and for me is like our "binary output code".
>>>
>>> Sorry to not be able to give any suggestion, but maybe as well an opinion
>>> of use is as well valuable.
>>>
>>> just my 2
>>>
>>>
>>> El mar., 11 dic. 2018 a las 21:24, Alex Harui (<ah...@adobe.com.invalid>)
>>> escribió:
>>>
>>>> Thinking about it more, -js-dynamic-access probably won't help. We don't
>>>> want to compile our SWCs with that option on and thus turn off minification
>>>> of these field names always if we can help it.
>>>>
>>>> Even a directive per occurrence won't help either. Whether a field name
>>>> is renamed is still dependent on what other code is in the compilation.
>>>>
>>>> The problem is better described as trying to find a way to control what
>>>> field names get renamed in more than one compilation, given that there is
>>>> pre-transpiled code that allows renaming. When building modules, we
>>>> already require using Closure Compiler options that output the renaming
>>>> maps of the main app so that UIBase is given the same short name in all
>>>> minifications. But there is no way to dictate that for field names as far
>>>> as I can tell.
>>>>
>>>> -Alex
>>>>
>>>> On 12/11/18, 11:32 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>
>>>> I vote for A.
>>>>
>>>> We can also do B which would require manually changing all access to
>>>> brackets and quote all names in object literals.
>>>>
>>>> I might be nice to add some comment decorations to enable/disable
>>>> -js-dynamic-access on a case-by-case basis, but I think it’s reasonable to
>>>> have a global on/off requirement. I’m already doing this for a library I
>>>> wrote which has a lot of dynamic data structures which does not survive
>>>> minification and the results are fine.
>>>>
>>>> My $0.02,
>>>> Harbs
>>>>
>>>>> On Dec 11, 2018, at 8:47 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>> wrote:
>>>>>
>>>>> IMO, some folks will want to rely on minification of object field
>>>> names so save space. I think -js-dynamic-access blocks minification.
>>>>>
>>>>> So, to try to pose the problem another way, you can rely on
>>>> minification object field names if you are building a single-js-file app,
>>>> but as soon as you start using modules, things may break. So what should
>>>> we tell folks?
>>>>>
>>>>> A) if you use modules you must turn off minification in objects with
>>>> -js-dynamic-access
>>>>> B) here are some ways to hack your code so you can still rely on
>>>> minification
>>>>> C) something else?
>>>>>
>>>>> We can manually rename fields in ROYALE_CLASS_INFO and other
>>>> structures to make our code less readable in debug mode but save space in
>>>> release mode, but that does not solve the general case problem. Folks may
>>>> have other objects in their apps and modules that work until you add some
>>>> code to one of the projects that changes which object fields get renamed.
>>>>>
>>>>> -Alex
>>>>>
>>>>> On 12/11/18, 9:31 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>
>>>>> I’m not following why this is the same point.
>>>>>
>>>>> I’m using -js-dynamic-access-unknown-members=true to handle this
>>>> kind of problem. It works flawlessly…
>>>>>
>>>>> I’d personally argue that true should be the default, but whether
>>>> the default is true or not, we do have an option to deal with these kinds
>>>> of data structures.
>>>>>
>>>>>> On Dec 11, 2018, at 6:39 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>> wrote:
>>>>>>
>>>>>> Yes, we can use our own short names in code we generate, but that's
>>>> not really the point.
>>>>>>
>>>>>> The point is that any plain object field can be renamed based on
>>>> other code in the compile. So if you just have:
>>>>>>
>>>>>> Var obj:Object = { harbs: 1};
>>>>>> Public static function foo()
>>>>>> {
>>>>>> Trace(obj.harbs);
>>>>>> }
>>>>>>
>>>>>> Use of foo() in one compile may result in harbs being renamed, and
>>>> another wouldn't. And that poses a problem when data structures are shared
>>>> between compiled outputs.
>>>>>>
>>>>>> This is a natural way to write AS, but the JS results when minified
>>>> and shared between app and modules can fail. So what restrictions should
>>>> we place if any on how folks use plain objects?
>>>>>>
>>>>>> HTH,
>>>>>> -Alex
>>>>>>
>>>>>> On 12/11/18, 7:36 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>
>>>>>> I was about to make the same suggestion. We can use “I” for
>>>> interfaces, “c” for class, “k” for kind, “n” for names. etc.
>>>>>>
>>>>>>> On Dec 11, 2018, at 2:52 PM, Frost, Andrew <An...@Harman.com>
>>>> wrote:
>>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> Not sure that I fully understand this but would a valid compromise
>>>> be something where the field name isn't renamed at all automatically, but
>>>> we just change it in the JS generation code to be "i" rather than
>>>> "interfaces", and update the Language is/as functions to work with this
>>>> property name? Not sure whether it would work and I don't know whether the
>>>> Reflection stuff would then need to change too, but if this is all in the
>>>> generated outputs and/or the framework's own code then it shouldn't be
>>>> something that the end user would bother about..
>>>>>>>
>>>>>>> thanks
>>>>>>>
>>>>>>> Andrew
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Alex Harui [mailto:aharui@adobe.com.INVALID]
>>>>>>> Sent: 11 December 2018 08:32
>>>>>>> To: dev@royale.apache.org
>>>>>>> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules, Objects
>>>>>>>
>>>>>>> I spent some time today trying to get Tour De Flex to run in
>>>> production mode with the main app and modules being separately minified.
>>>>>>>
>>>>>>> I've fixed a few things here and there, but an interesting issue I
>>>> ran into has to do with the plain object we use in ROYALE_CLASS_INFO (and
>>>> will apply to other objects).
>>>>>>>
>>>>>>> The ROYALE_CLASS_INFO is generated on each class and has a "names"
>>>> property and an optional "interfaces" property. An example is:
>>>>>>>
>>>>>>>
>>>> org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO
>>>> = { names: [{ name: 'PanelModel', qName:
>>>> 'org.apache.royale.html.beads.models.PanelModel', kind: 'class' }],
>>>> interfaces: [org.apache.royale.core.IBead,
>>>> org.apache.royale.core.IPanelModel] };
>>>>>>>
>>>>>>> Because the field names are not quoted, then in most output, the
>>>> field name "interfaces" is renamed and all code referencing this field is
>>>> renamed as well. This is good because it means that you don't have to
>>>> download the word "interfaces" once per-class. Instead of 10 characters, it
>>>> is usually one or two. 100 classes saves you about 900 bytes.
>>>>>>>
>>>>>>> However, it turns out that in Tour De Flex, the main app uses
>>>> Reflection and Reflection uses a quoted 'interfaces' string and thus, the
>>>> field name 'interfaces' in ROYALE_CLASS_INFO isn't renamed, but in most
>>>> modules "interfaces" is renamed since no other code in the module has a
>>>> quoted string for 'interfaces'. But that means that when a module loads,
>>>> the Language.is/as won't work since classes in the main app are using
>>>> "interfaces" but the classes in the module are using some short name.
>>>>>>>
>>>>>>> One solution is to always quote that field in the compiler output
>>>> and Language is/as so it doesn't get renamed, but that means that field
>>>> will never get renamed and you lose saving those bytes.
>>>>>>>
>>>>>>> Another is let folks figure out their own workarounds, by adding
>>>> some code that will prevent the renaming in the modules.
>>>>>>>
>>>>>>> Other ideas are welcome. I'm done for tonight.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>> -Alex
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Carlos Rovira
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2c36443f61b4436324ee08d65fb6a252%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636801635412696785&sdata=DwG2KMwX7oKIaag1NeuP%2BnNwPp4VD7amvdLaKmPQ7H8%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2c36443f61b4436324ee08d65fb6a252%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636801635412696785&sdata=DwG2KMwX7oKIaag1NeuP%2BnNwPp4VD7amvdLaKmPQ7H8%3D&reserved=0>
Re: ROYALE_CLASS_INFO, renaming, modules, Objects
Posted by Harbs <ha...@gmail.com>.
I’m still not getting the connection to ROYALE_CLASS_INFO.
Can you explain to me in pseudo-code the problem with that? Why does a dynamic object have ROYALE_CLASS_INFO at all?
> On Dec 12, 2018, at 12:16 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> I'm not sure why you think it is theoretical. For sure, in TDF, the module is not loading because ROYALE_CLASS_INFO is minified differently in the main app than the module. Any dynamic objects shared across compilations are at risk of being renamed differently. I'm chasing down a way to control it.
>
> We do have control over the names of classes and properties to guarantee they are the same in the app and module. It is just these dynamic object keys that we don't yet have control over.
>
> We do have the option of defining a class for ROYALE_CLASS_INFO, but then it will never minify. I like the fact that it can minify without us having to use shortnames. It makes our debug code more readable and doesn't waste space in small apps. Adding a class definition for ROYALE_CLASS_INFO would further add overhead to small apps.
>
> My 2 cents,
> -Alex
>
> On 12/11/18, 2:06 PM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>
> In fact, in looking through the framework code so far, the only place I’ve found variable names not quoted (in JS compatible code) so far was in CSSUtils where we have a colorMap. I’m pretty sure the colorMap will not work after minification because the color names will not match…
>
>> On Dec 12, 2018, at 12:01 AM, Harbs <ha...@gmail.com> wrote:
>>
>> Hi Carlos,
>>
>> We’re only discussing dynamic objects. How many of those do you have in your applications? I doubt there’s much difference in performance due to minification of dynamic objects.
>>
>> In *all* our framework code we have dynamic object instantiation in 435 places including TLF, Spark and MX classes. Without those packages, I’m estimating it’s a small fraction of that and probably most of the dynamic objects are hash maps where they don’t benefit from minification anyway.
>>
>> The vast majority of the cases where you’re using dynamic objects in production code you don’t want the names minified either (i.e. API calls and uses of JSON).
>>
>> I think that most of this discussion is more theoretical than practical considerations.
>>
>> My $0.02,
>> Harbs
>>
>>> On Dec 11, 2018, at 11:26 PM, Carlos Rovira <ca...@apache.org> wrote:
>>>
>>> Hi,
>>>
>>> I'm still not using modules. I left that for now until we complete the
>>> first phase in our project, but will be using (hopefully) around February.
>>>
>>> So right now we're only using minification, that seems not only to reduce
>>> the size of the build, but release mode performs faster, and I think is
>>> due, in part, to minify.
>>>
>>> So, IMHO, as a user, I don't like A). Can't think of a solution, since is
>>> not my zone of expertise, and sure you guys found a good solution after
>>> all. Just want to say that as a user, is importante both things: have
>>> modules (and hope we could link as well with routing like people do in
>>> other current techs like React and Angular to get a powerful solution for
>>> SPAs) and have minification, since IMO, the resultant js-release build has
>>> many, many advantages, not only in performance and size but as well in
>>> obfuscation, and for me is like our "binary output code".
>>>
>>> Sorry to not be able to give any suggestion, but maybe as well an opinion
>>> of use is as well valuable.
>>>
>>> just my 2
>>>
>>>
>>> El mar., 11 dic. 2018 a las 21:24, Alex Harui (<ah...@adobe.com.invalid>)
>>> escribió:
>>>
>>>> Thinking about it more, -js-dynamic-access probably won't help. We don't
>>>> want to compile our SWCs with that option on and thus turn off minification
>>>> of these field names always if we can help it.
>>>>
>>>> Even a directive per occurrence won't help either. Whether a field name
>>>> is renamed is still dependent on what other code is in the compilation.
>>>>
>>>> The problem is better described as trying to find a way to control what
>>>> field names get renamed in more than one compilation, given that there is
>>>> pre-transpiled code that allows renaming. When building modules, we
>>>> already require using Closure Compiler options that output the renaming
>>>> maps of the main app so that UIBase is given the same short name in all
>>>> minifications. But there is no way to dictate that for field names as far
>>>> as I can tell.
>>>>
>>>> -Alex
>>>>
>>>> On 12/11/18, 11:32 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>
>>>> I vote for A.
>>>>
>>>> We can also do B which would require manually changing all access to
>>>> brackets and quote all names in object literals.
>>>>
>>>> I might be nice to add some comment decorations to enable/disable
>>>> -js-dynamic-access on a case-by-case basis, but I think it’s reasonable to
>>>> have a global on/off requirement. I’m already doing this for a library I
>>>> wrote which has a lot of dynamic data structures which does not survive
>>>> minification and the results are fine.
>>>>
>>>> My $0.02,
>>>> Harbs
>>>>
>>>>> On Dec 11, 2018, at 8:47 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>> wrote:
>>>>>
>>>>> IMO, some folks will want to rely on minification of object field
>>>> names so save space. I think -js-dynamic-access blocks minification.
>>>>>
>>>>> So, to try to pose the problem another way, you can rely on
>>>> minification object field names if you are building a single-js-file app,
>>>> but as soon as you start using modules, things may break. So what should
>>>> we tell folks?
>>>>>
>>>>> A) if you use modules you must turn off minification in objects with
>>>> -js-dynamic-access
>>>>> B) here are some ways to hack your code so you can still rely on
>>>> minification
>>>>> C) something else?
>>>>>
>>>>> We can manually rename fields in ROYALE_CLASS_INFO and other
>>>> structures to make our code less readable in debug mode but save space in
>>>> release mode, but that does not solve the general case problem. Folks may
>>>> have other objects in their apps and modules that work until you add some
>>>> code to one of the projects that changes which object fields get renamed.
>>>>>
>>>>> -Alex
>>>>>
>>>>> On 12/11/18, 9:31 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>
>>>>> I’m not following why this is the same point.
>>>>>
>>>>> I’m using -js-dynamic-access-unknown-members=true to handle this
>>>> kind of problem. It works flawlessly…
>>>>>
>>>>> I’d personally argue that true should be the default, but whether
>>>> the default is true or not, we do have an option to deal with these kinds
>>>> of data structures.
>>>>>
>>>>>> On Dec 11, 2018, at 6:39 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>> wrote:
>>>>>>
>>>>>> Yes, we can use our own short names in code we generate, but that's
>>>> not really the point.
>>>>>>
>>>>>> The point is that any plain object field can be renamed based on
>>>> other code in the compile. So if you just have:
>>>>>>
>>>>>> Var obj:Object = { harbs: 1};
>>>>>> Public static function foo()
>>>>>> {
>>>>>> Trace(obj.harbs);
>>>>>> }
>>>>>>
>>>>>> Use of foo() in one compile may result in harbs being renamed, and
>>>> another wouldn't. And that poses a problem when data structures are shared
>>>> between compiled outputs.
>>>>>>
>>>>>> This is a natural way to write AS, but the JS results when minified
>>>> and shared between app and modules can fail. So what restrictions should
>>>> we place if any on how folks use plain objects?
>>>>>>
>>>>>> HTH,
>>>>>> -Alex
>>>>>>
>>>>>> On 12/11/18, 7:36 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>
>>>>>> I was about to make the same suggestion. We can use “I” for
>>>> interfaces, “c” for class, “k” for kind, “n” for names. etc.
>>>>>>
>>>>>>> On Dec 11, 2018, at 2:52 PM, Frost, Andrew <An...@Harman.com>
>>>> wrote:
>>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> Not sure that I fully understand this but would a valid compromise
>>>> be something where the field name isn't renamed at all automatically, but
>>>> we just change it in the JS generation code to be "i" rather than
>>>> "interfaces", and update the Language is/as functions to work with this
>>>> property name? Not sure whether it would work and I don't know whether the
>>>> Reflection stuff would then need to change too, but if this is all in the
>>>> generated outputs and/or the framework's own code then it shouldn't be
>>>> something that the end user would bother about..
>>>>>>>
>>>>>>> thanks
>>>>>>>
>>>>>>> Andrew
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Alex Harui [mailto:aharui@adobe.com.INVALID]
>>>>>>> Sent: 11 December 2018 08:32
>>>>>>> To: dev@royale.apache.org
>>>>>>> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules, Objects
>>>>>>>
>>>>>>> I spent some time today trying to get Tour De Flex to run in
>>>> production mode with the main app and modules being separately minified.
>>>>>>>
>>>>>>> I've fixed a few things here and there, but an interesting issue I
>>>> ran into has to do with the plain object we use in ROYALE_CLASS_INFO (and
>>>> will apply to other objects).
>>>>>>>
>>>>>>> The ROYALE_CLASS_INFO is generated on each class and has a "names"
>>>> property and an optional "interfaces" property. An example is:
>>>>>>>
>>>>>>>
>>>> org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO
>>>> = { names: [{ name: 'PanelModel', qName:
>>>> 'org.apache.royale.html.beads.models.PanelModel', kind: 'class' }],
>>>> interfaces: [org.apache.royale.core.IBead,
>>>> org.apache.royale.core.IPanelModel] };
>>>>>>>
>>>>>>> Because the field names are not quoted, then in most output, the
>>>> field name "interfaces" is renamed and all code referencing this field is
>>>> renamed as well. This is good because it means that you don't have to
>>>> download the word "interfaces" once per-class. Instead of 10 characters, it
>>>> is usually one or two. 100 classes saves you about 900 bytes.
>>>>>>>
>>>>>>> However, it turns out that in Tour De Flex, the main app uses
>>>> Reflection and Reflection uses a quoted 'interfaces' string and thus, the
>>>> field name 'interfaces' in ROYALE_CLASS_INFO isn't renamed, but in most
>>>> modules "interfaces" is renamed since no other code in the module has a
>>>> quoted string for 'interfaces'. But that means that when a module loads,
>>>> the Language.is/as won't work since classes in the main app are using
>>>> "interfaces" but the classes in the module are using some short name.
>>>>>>>
>>>>>>> One solution is to always quote that field in the compiler output
>>>> and Language is/as so it doesn't get renamed, but that means that field
>>>> will never get renamed and you lose saving those bytes.
>>>>>>>
>>>>>>> Another is let folks figure out their own workarounds, by adding
>>>> some code that will prevent the renaming in the modules.
>>>>>>>
>>>>>>> Other ideas are welcome. I'm done for tonight.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>> -Alex
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Carlos Rovira
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9352465ee77d4ca2739608d65fb4e1b1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636801627815834341&sdata=4dFC9NbGf9%2F87sFR8kgOr5ejZIgnVwMlKCPi68mwZzo%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9352465ee77d4ca2739608d65fb4e1b1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636801627815834341&sdata=4dFC9NbGf9%2F87sFR8kgOr5ejZIgnVwMlKCPi68mwZzo%3D&reserved=0>
Re: ROYALE_CLASS_INFO, renaming, modules, Objects
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I'm not sure why you think it is theoretical. For sure, in TDF, the module is not loading because ROYALE_CLASS_INFO is minified differently in the main app than the module. Any dynamic objects shared across compilations are at risk of being renamed differently. I'm chasing down a way to control it.
We do have control over the names of classes and properties to guarantee they are the same in the app and module. It is just these dynamic object keys that we don't yet have control over.
We do have the option of defining a class for ROYALE_CLASS_INFO, but then it will never minify. I like the fact that it can minify without us having to use shortnames. It makes our debug code more readable and doesn't waste space in small apps. Adding a class definition for ROYALE_CLASS_INFO would further add overhead to small apps.
My 2 cents,
-Alex
On 12/11/18, 2:06 PM, "Harbs" <ha...@gmail.com> wrote:
In fact, in looking through the framework code so far, the only place I’ve found variable names not quoted (in JS compatible code) so far was in CSSUtils where we have a colorMap. I’m pretty sure the colorMap will not work after minification because the color names will not match…
> On Dec 12, 2018, at 12:01 AM, Harbs <ha...@gmail.com> wrote:
>
> Hi Carlos,
>
> We’re only discussing dynamic objects. How many of those do you have in your applications? I doubt there’s much difference in performance due to minification of dynamic objects.
>
> In *all* our framework code we have dynamic object instantiation in 435 places including TLF, Spark and MX classes. Without those packages, I’m estimating it’s a small fraction of that and probably most of the dynamic objects are hash maps where they don’t benefit from minification anyway.
>
> The vast majority of the cases where you’re using dynamic objects in production code you don’t want the names minified either (i.e. API calls and uses of JSON).
>
> I think that most of this discussion is more theoretical than practical considerations.
>
> My $0.02,
> Harbs
>
>> On Dec 11, 2018, at 11:26 PM, Carlos Rovira <ca...@apache.org> wrote:
>>
>> Hi,
>>
>> I'm still not using modules. I left that for now until we complete the
>> first phase in our project, but will be using (hopefully) around February.
>>
>> So right now we're only using minification, that seems not only to reduce
>> the size of the build, but release mode performs faster, and I think is
>> due, in part, to minify.
>>
>> So, IMHO, as a user, I don't like A). Can't think of a solution, since is
>> not my zone of expertise, and sure you guys found a good solution after
>> all. Just want to say that as a user, is importante both things: have
>> modules (and hope we could link as well with routing like people do in
>> other current techs like React and Angular to get a powerful solution for
>> SPAs) and have minification, since IMO, the resultant js-release build has
>> many, many advantages, not only in performance and size but as well in
>> obfuscation, and for me is like our "binary output code".
>>
>> Sorry to not be able to give any suggestion, but maybe as well an opinion
>> of use is as well valuable.
>>
>> just my 2
>>
>>
>> El mar., 11 dic. 2018 a las 21:24, Alex Harui (<ah...@adobe.com.invalid>)
>> escribió:
>>
>>> Thinking about it more, -js-dynamic-access probably won't help. We don't
>>> want to compile our SWCs with that option on and thus turn off minification
>>> of these field names always if we can help it.
>>>
>>> Even a directive per occurrence won't help either. Whether a field name
>>> is renamed is still dependent on what other code is in the compilation.
>>>
>>> The problem is better described as trying to find a way to control what
>>> field names get renamed in more than one compilation, given that there is
>>> pre-transpiled code that allows renaming. When building modules, we
>>> already require using Closure Compiler options that output the renaming
>>> maps of the main app so that UIBase is given the same short name in all
>>> minifications. But there is no way to dictate that for field names as far
>>> as I can tell.
>>>
>>> -Alex
>>>
>>> On 12/11/18, 11:32 AM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>> I vote for A.
>>>
>>> We can also do B which would require manually changing all access to
>>> brackets and quote all names in object literals.
>>>
>>> I might be nice to add some comment decorations to enable/disable
>>> -js-dynamic-access on a case-by-case basis, but I think it’s reasonable to
>>> have a global on/off requirement. I’m already doing this for a library I
>>> wrote which has a lot of dynamic data structures which does not survive
>>> minification and the results are fine.
>>>
>>> My $0.02,
>>> Harbs
>>>
>>>> On Dec 11, 2018, at 8:47 PM, Alex Harui <ah...@adobe.com.INVALID>
>>> wrote:
>>>>
>>>> IMO, some folks will want to rely on minification of object field
>>> names so save space. I think -js-dynamic-access blocks minification.
>>>>
>>>> So, to try to pose the problem another way, you can rely on
>>> minification object field names if you are building a single-js-file app,
>>> but as soon as you start using modules, things may break. So what should
>>> we tell folks?
>>>>
>>>> A) if you use modules you must turn off minification in objects with
>>> -js-dynamic-access
>>>> B) here are some ways to hack your code so you can still rely on
>>> minification
>>>> C) something else?
>>>>
>>>> We can manually rename fields in ROYALE_CLASS_INFO and other
>>> structures to make our code less readable in debug mode but save space in
>>> release mode, but that does not solve the general case problem. Folks may
>>> have other objects in their apps and modules that work until you add some
>>> code to one of the projects that changes which object fields get renamed.
>>>>
>>>> -Alex
>>>>
>>>> On 12/11/18, 9:31 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>
>>>> I’m not following why this is the same point.
>>>>
>>>> I’m using -js-dynamic-access-unknown-members=true to handle this
>>> kind of problem. It works flawlessly…
>>>>
>>>> I’d personally argue that true should be the default, but whether
>>> the default is true or not, we do have an option to deal with these kinds
>>> of data structures.
>>>>
>>>>> On Dec 11, 2018, at 6:39 PM, Alex Harui <ah...@adobe.com.INVALID>
>>> wrote:
>>>>>
>>>>> Yes, we can use our own short names in code we generate, but that's
>>> not really the point.
>>>>>
>>>>> The point is that any plain object field can be renamed based on
>>> other code in the compile. So if you just have:
>>>>>
>>>>> Var obj:Object = { harbs: 1};
>>>>> Public static function foo()
>>>>> {
>>>>> Trace(obj.harbs);
>>>>> }
>>>>>
>>>>> Use of foo() in one compile may result in harbs being renamed, and
>>> another wouldn't. And that poses a problem when data structures are shared
>>> between compiled outputs.
>>>>>
>>>>> This is a natural way to write AS, but the JS results when minified
>>> and shared between app and modules can fail. So what restrictions should
>>> we place if any on how folks use plain objects?
>>>>>
>>>>> HTH,
>>>>> -Alex
>>>>>
>>>>> On 12/11/18, 7:36 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>
>>>>> I was about to make the same suggestion. We can use “I” for
>>> interfaces, “c” for class, “k” for kind, “n” for names. etc.
>>>>>
>>>>>> On Dec 11, 2018, at 2:52 PM, Frost, Andrew <An...@Harman.com>
>>> wrote:
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>> Not sure that I fully understand this but would a valid compromise
>>> be something where the field name isn't renamed at all automatically, but
>>> we just change it in the JS generation code to be "i" rather than
>>> "interfaces", and update the Language is/as functions to work with this
>>> property name? Not sure whether it would work and I don't know whether the
>>> Reflection stuff would then need to change too, but if this is all in the
>>> generated outputs and/or the framework's own code then it shouldn't be
>>> something that the end user would bother about..
>>>>>>
>>>>>> thanks
>>>>>>
>>>>>> Andrew
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Alex Harui [mailto:aharui@adobe.com.INVALID]
>>>>>> Sent: 11 December 2018 08:32
>>>>>> To: dev@royale.apache.org
>>>>>> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules, Objects
>>>>>>
>>>>>> I spent some time today trying to get Tour De Flex to run in
>>> production mode with the main app and modules being separately minified.
>>>>>>
>>>>>> I've fixed a few things here and there, but an interesting issue I
>>> ran into has to do with the plain object we use in ROYALE_CLASS_INFO (and
>>> will apply to other objects).
>>>>>>
>>>>>> The ROYALE_CLASS_INFO is generated on each class and has a "names"
>>> property and an optional "interfaces" property. An example is:
>>>>>>
>>>>>>
>>> org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO
>>> = { names: [{ name: 'PanelModel', qName:
>>> 'org.apache.royale.html.beads.models.PanelModel', kind: 'class' }],
>>> interfaces: [org.apache.royale.core.IBead,
>>> org.apache.royale.core.IPanelModel] };
>>>>>>
>>>>>> Because the field names are not quoted, then in most output, the
>>> field name "interfaces" is renamed and all code referencing this field is
>>> renamed as well. This is good because it means that you don't have to
>>> download the word "interfaces" once per-class. Instead of 10 characters, it
>>> is usually one or two. 100 classes saves you about 900 bytes.
>>>>>>
>>>>>> However, it turns out that in Tour De Flex, the main app uses
>>> Reflection and Reflection uses a quoted 'interfaces' string and thus, the
>>> field name 'interfaces' in ROYALE_CLASS_INFO isn't renamed, but in most
>>> modules "interfaces" is renamed since no other code in the module has a
>>> quoted string for 'interfaces'. But that means that when a module loads,
>>> the Language.is/as won't work since classes in the main app are using
>>> "interfaces" but the classes in the module are using some short name.
>>>>>>
>>>>>> One solution is to always quote that field in the compiler output
>>> and Language is/as so it doesn't get renamed, but that means that field
>>> will never get renamed and you lose saving those bytes.
>>>>>>
>>>>>> Another is let folks figure out their own workarounds, by adding
>>> some code that will prevent the renaming in the modules.
>>>>>>
>>>>>> Other ideas are welcome. I'm done for tonight.
>>>>>>
>>>>>> Thoughts?
>>>>>> -Alex
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Carlos Rovira
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9352465ee77d4ca2739608d65fb4e1b1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636801627815834341&sdata=4dFC9NbGf9%2F87sFR8kgOr5ejZIgnVwMlKCPi68mwZzo%3D&reserved=0
>
Re: ROYALE_CLASS_INFO, renaming, modules, Objects
Posted by Harbs <ha...@gmail.com>.
In fact, in looking through the framework code so far, the only place I’ve found variable names not quoted (in JS compatible code) so far was in CSSUtils where we have a colorMap. I’m pretty sure the colorMap will not work after minification because the color names will not match…
> On Dec 12, 2018, at 12:01 AM, Harbs <ha...@gmail.com> wrote:
>
> Hi Carlos,
>
> We’re only discussing dynamic objects. How many of those do you have in your applications? I doubt there’s much difference in performance due to minification of dynamic objects.
>
> In *all* our framework code we have dynamic object instantiation in 435 places including TLF, Spark and MX classes. Without those packages, I’m estimating it’s a small fraction of that and probably most of the dynamic objects are hash maps where they don’t benefit from minification anyway.
>
> The vast majority of the cases where you’re using dynamic objects in production code you don’t want the names minified either (i.e. API calls and uses of JSON).
>
> I think that most of this discussion is more theoretical than practical considerations.
>
> My $0.02,
> Harbs
>
>> On Dec 11, 2018, at 11:26 PM, Carlos Rovira <ca...@apache.org> wrote:
>>
>> Hi,
>>
>> I'm still not using modules. I left that for now until we complete the
>> first phase in our project, but will be using (hopefully) around February.
>>
>> So right now we're only using minification, that seems not only to reduce
>> the size of the build, but release mode performs faster, and I think is
>> due, in part, to minify.
>>
>> So, IMHO, as a user, I don't like A). Can't think of a solution, since is
>> not my zone of expertise, and sure you guys found a good solution after
>> all. Just want to say that as a user, is importante both things: have
>> modules (and hope we could link as well with routing like people do in
>> other current techs like React and Angular to get a powerful solution for
>> SPAs) and have minification, since IMO, the resultant js-release build has
>> many, many advantages, not only in performance and size but as well in
>> obfuscation, and for me is like our "binary output code".
>>
>> Sorry to not be able to give any suggestion, but maybe as well an opinion
>> of use is as well valuable.
>>
>> just my 2
>>
>>
>> El mar., 11 dic. 2018 a las 21:24, Alex Harui (<ah...@adobe.com.invalid>)
>> escribió:
>>
>>> Thinking about it more, -js-dynamic-access probably won't help. We don't
>>> want to compile our SWCs with that option on and thus turn off minification
>>> of these field names always if we can help it.
>>>
>>> Even a directive per occurrence won't help either. Whether a field name
>>> is renamed is still dependent on what other code is in the compilation.
>>>
>>> The problem is better described as trying to find a way to control what
>>> field names get renamed in more than one compilation, given that there is
>>> pre-transpiled code that allows renaming. When building modules, we
>>> already require using Closure Compiler options that output the renaming
>>> maps of the main app so that UIBase is given the same short name in all
>>> minifications. But there is no way to dictate that for field names as far
>>> as I can tell.
>>>
>>> -Alex
>>>
>>> On 12/11/18, 11:32 AM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>> I vote for A.
>>>
>>> We can also do B which would require manually changing all access to
>>> brackets and quote all names in object literals.
>>>
>>> I might be nice to add some comment decorations to enable/disable
>>> -js-dynamic-access on a case-by-case basis, but I think it’s reasonable to
>>> have a global on/off requirement. I’m already doing this for a library I
>>> wrote which has a lot of dynamic data structures which does not survive
>>> minification and the results are fine.
>>>
>>> My $0.02,
>>> Harbs
>>>
>>>> On Dec 11, 2018, at 8:47 PM, Alex Harui <ah...@adobe.com.INVALID>
>>> wrote:
>>>>
>>>> IMO, some folks will want to rely on minification of object field
>>> names so save space. I think -js-dynamic-access blocks minification.
>>>>
>>>> So, to try to pose the problem another way, you can rely on
>>> minification object field names if you are building a single-js-file app,
>>> but as soon as you start using modules, things may break. So what should
>>> we tell folks?
>>>>
>>>> A) if you use modules you must turn off minification in objects with
>>> -js-dynamic-access
>>>> B) here are some ways to hack your code so you can still rely on
>>> minification
>>>> C) something else?
>>>>
>>>> We can manually rename fields in ROYALE_CLASS_INFO and other
>>> structures to make our code less readable in debug mode but save space in
>>> release mode, but that does not solve the general case problem. Folks may
>>> have other objects in their apps and modules that work until you add some
>>> code to one of the projects that changes which object fields get renamed.
>>>>
>>>> -Alex
>>>>
>>>> On 12/11/18, 9:31 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>
>>>> I’m not following why this is the same point.
>>>>
>>>> I’m using -js-dynamic-access-unknown-members=true to handle this
>>> kind of problem. It works flawlessly…
>>>>
>>>> I’d personally argue that true should be the default, but whether
>>> the default is true or not, we do have an option to deal with these kinds
>>> of data structures.
>>>>
>>>>> On Dec 11, 2018, at 6:39 PM, Alex Harui <ah...@adobe.com.INVALID>
>>> wrote:
>>>>>
>>>>> Yes, we can use our own short names in code we generate, but that's
>>> not really the point.
>>>>>
>>>>> The point is that any plain object field can be renamed based on
>>> other code in the compile. So if you just have:
>>>>>
>>>>> Var obj:Object = { harbs: 1};
>>>>> Public static function foo()
>>>>> {
>>>>> Trace(obj.harbs);
>>>>> }
>>>>>
>>>>> Use of foo() in one compile may result in harbs being renamed, and
>>> another wouldn't. And that poses a problem when data structures are shared
>>> between compiled outputs.
>>>>>
>>>>> This is a natural way to write AS, but the JS results when minified
>>> and shared between app and modules can fail. So what restrictions should
>>> we place if any on how folks use plain objects?
>>>>>
>>>>> HTH,
>>>>> -Alex
>>>>>
>>>>> On 12/11/18, 7:36 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>
>>>>> I was about to make the same suggestion. We can use “I” for
>>> interfaces, “c” for class, “k” for kind, “n” for names. etc.
>>>>>
>>>>>> On Dec 11, 2018, at 2:52 PM, Frost, Andrew <An...@Harman.com>
>>> wrote:
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>> Not sure that I fully understand this but would a valid compromise
>>> be something where the field name isn't renamed at all automatically, but
>>> we just change it in the JS generation code to be "i" rather than
>>> "interfaces", and update the Language is/as functions to work with this
>>> property name? Not sure whether it would work and I don't know whether the
>>> Reflection stuff would then need to change too, but if this is all in the
>>> generated outputs and/or the framework's own code then it shouldn't be
>>> something that the end user would bother about..
>>>>>>
>>>>>> thanks
>>>>>>
>>>>>> Andrew
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Alex Harui [mailto:aharui@adobe.com.INVALID]
>>>>>> Sent: 11 December 2018 08:32
>>>>>> To: dev@royale.apache.org
>>>>>> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules, Objects
>>>>>>
>>>>>> I spent some time today trying to get Tour De Flex to run in
>>> production mode with the main app and modules being separately minified.
>>>>>>
>>>>>> I've fixed a few things here and there, but an interesting issue I
>>> ran into has to do with the plain object we use in ROYALE_CLASS_INFO (and
>>> will apply to other objects).
>>>>>>
>>>>>> The ROYALE_CLASS_INFO is generated on each class and has a "names"
>>> property and an optional "interfaces" property. An example is:
>>>>>>
>>>>>>
>>> org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO
>>> = { names: [{ name: 'PanelModel', qName:
>>> 'org.apache.royale.html.beads.models.PanelModel', kind: 'class' }],
>>> interfaces: [org.apache.royale.core.IBead,
>>> org.apache.royale.core.IPanelModel] };
>>>>>>
>>>>>> Because the field names are not quoted, then in most output, the
>>> field name "interfaces" is renamed and all code referencing this field is
>>> renamed as well. This is good because it means that you don't have to
>>> download the word "interfaces" once per-class. Instead of 10 characters, it
>>> is usually one or two. 100 classes saves you about 900 bytes.
>>>>>>
>>>>>> However, it turns out that in Tour De Flex, the main app uses
>>> Reflection and Reflection uses a quoted 'interfaces' string and thus, the
>>> field name 'interfaces' in ROYALE_CLASS_INFO isn't renamed, but in most
>>> modules "interfaces" is renamed since no other code in the module has a
>>> quoted string for 'interfaces'. But that means that when a module loads,
>>> the Language.is/as won't work since classes in the main app are using
>>> "interfaces" but the classes in the module are using some short name.
>>>>>>
>>>>>> One solution is to always quote that field in the compiler output
>>> and Language is/as so it doesn't get renamed, but that means that field
>>> will never get renamed and you lose saving those bytes.
>>>>>>
>>>>>> Another is let folks figure out their own workarounds, by adding
>>> some code that will prevent the renaming in the modules.
>>>>>>
>>>>>> Other ideas are welcome. I'm done for tonight.
>>>>>>
>>>>>> Thoughts?
>>>>>> -Alex
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>
Re: ROYALE_CLASS_INFO, renaming, modules, Objects
Posted by Harbs <ha...@gmail.com>.
Hi Carlos,
We’re only discussing dynamic objects. How many of those do you have in your applications? I doubt there’s much difference in performance due to minification of dynamic objects.
In *all* our framework code we have dynamic object instantiation in 435 places including TLF, Spark and MX classes. Without those packages, I’m estimating it’s a small fraction of that and probably most of the dynamic objects are hash maps where they don’t benefit from minification anyway.
The vast majority of the cases where you’re using dynamic objects in production code you don’t want the names minified either (i.e. API calls and uses of JSON).
I think that most of this discussion is more theoretical than practical considerations.
My $0.02,
Harbs
> On Dec 11, 2018, at 11:26 PM, Carlos Rovira <ca...@apache.org> wrote:
>
> Hi,
>
> I'm still not using modules. I left that for now until we complete the
> first phase in our project, but will be using (hopefully) around February.
>
> So right now we're only using minification, that seems not only to reduce
> the size of the build, but release mode performs faster, and I think is
> due, in part, to minify.
>
> So, IMHO, as a user, I don't like A). Can't think of a solution, since is
> not my zone of expertise, and sure you guys found a good solution after
> all. Just want to say that as a user, is importante both things: have
> modules (and hope we could link as well with routing like people do in
> other current techs like React and Angular to get a powerful solution for
> SPAs) and have minification, since IMO, the resultant js-release build has
> many, many advantages, not only in performance and size but as well in
> obfuscation, and for me is like our "binary output code".
>
> Sorry to not be able to give any suggestion, but maybe as well an opinion
> of use is as well valuable.
>
> just my 2
>
>
> El mar., 11 dic. 2018 a las 21:24, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
>> Thinking about it more, -js-dynamic-access probably won't help. We don't
>> want to compile our SWCs with that option on and thus turn off minification
>> of these field names always if we can help it.
>>
>> Even a directive per occurrence won't help either. Whether a field name
>> is renamed is still dependent on what other code is in the compilation.
>>
>> The problem is better described as trying to find a way to control what
>> field names get renamed in more than one compilation, given that there is
>> pre-transpiled code that allows renaming. When building modules, we
>> already require using Closure Compiler options that output the renaming
>> maps of the main app so that UIBase is given the same short name in all
>> minifications. But there is no way to dictate that for field names as far
>> as I can tell.
>>
>> -Alex
>>
>> On 12/11/18, 11:32 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>> I vote for A.
>>
>> We can also do B which would require manually changing all access to
>> brackets and quote all names in object literals.
>>
>> I might be nice to add some comment decorations to enable/disable
>> -js-dynamic-access on a case-by-case basis, but I think it’s reasonable to
>> have a global on/off requirement. I’m already doing this for a library I
>> wrote which has a lot of dynamic data structures which does not survive
>> minification and the results are fine.
>>
>> My $0.02,
>> Harbs
>>
>>> On Dec 11, 2018, at 8:47 PM, Alex Harui <ah...@adobe.com.INVALID>
>> wrote:
>>>
>>> IMO, some folks will want to rely on minification of object field
>> names so save space. I think -js-dynamic-access blocks minification.
>>>
>>> So, to try to pose the problem another way, you can rely on
>> minification object field names if you are building a single-js-file app,
>> but as soon as you start using modules, things may break. So what should
>> we tell folks?
>>>
>>> A) if you use modules you must turn off minification in objects with
>> -js-dynamic-access
>>> B) here are some ways to hack your code so you can still rely on
>> minification
>>> C) something else?
>>>
>>> We can manually rename fields in ROYALE_CLASS_INFO and other
>> structures to make our code less readable in debug mode but save space in
>> release mode, but that does not solve the general case problem. Folks may
>> have other objects in their apps and modules that work until you add some
>> code to one of the projects that changes which object fields get renamed.
>>>
>>> -Alex
>>>
>>> On 12/11/18, 9:31 AM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>> I’m not following why this is the same point.
>>>
>>> I’m using -js-dynamic-access-unknown-members=true to handle this
>> kind of problem. It works flawlessly…
>>>
>>> I’d personally argue that true should be the default, but whether
>> the default is true or not, we do have an option to deal with these kinds
>> of data structures.
>>>
>>>> On Dec 11, 2018, at 6:39 PM, Alex Harui <ah...@adobe.com.INVALID>
>> wrote:
>>>>
>>>> Yes, we can use our own short names in code we generate, but that's
>> not really the point.
>>>>
>>>> The point is that any plain object field can be renamed based on
>> other code in the compile. So if you just have:
>>>>
>>>> Var obj:Object = { harbs: 1};
>>>> Public static function foo()
>>>> {
>>>> Trace(obj.harbs);
>>>> }
>>>>
>>>> Use of foo() in one compile may result in harbs being renamed, and
>> another wouldn't. And that poses a problem when data structures are shared
>> between compiled outputs.
>>>>
>>>> This is a natural way to write AS, but the JS results when minified
>> and shared between app and modules can fail. So what restrictions should
>> we place if any on how folks use plain objects?
>>>>
>>>> HTH,
>>>> -Alex
>>>>
>>>> On 12/11/18, 7:36 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>
>>>> I was about to make the same suggestion. We can use “I” for
>> interfaces, “c” for class, “k” for kind, “n” for names. etc.
>>>>
>>>>> On Dec 11, 2018, at 2:52 PM, Frost, Andrew <An...@Harman.com>
>> wrote:
>>>>>
>>>>> Hi
>>>>>
>>>>> Not sure that I fully understand this but would a valid compromise
>> be something where the field name isn't renamed at all automatically, but
>> we just change it in the JS generation code to be "i" rather than
>> "interfaces", and update the Language is/as functions to work with this
>> property name? Not sure whether it would work and I don't know whether the
>> Reflection stuff would then need to change too, but if this is all in the
>> generated outputs and/or the framework's own code then it shouldn't be
>> something that the end user would bother about..
>>>>>
>>>>> thanks
>>>>>
>>>>> Andrew
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Alex Harui [mailto:aharui@adobe.com.INVALID]
>>>>> Sent: 11 December 2018 08:32
>>>>> To: dev@royale.apache.org
>>>>> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules, Objects
>>>>>
>>>>> I spent some time today trying to get Tour De Flex to run in
>> production mode with the main app and modules being separately minified.
>>>>>
>>>>> I've fixed a few things here and there, but an interesting issue I
>> ran into has to do with the plain object we use in ROYALE_CLASS_INFO (and
>> will apply to other objects).
>>>>>
>>>>> The ROYALE_CLASS_INFO is generated on each class and has a "names"
>> property and an optional "interfaces" property. An example is:
>>>>>
>>>>>
>> org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO
>> = { names: [{ name: 'PanelModel', qName:
>> 'org.apache.royale.html.beads.models.PanelModel', kind: 'class' }],
>> interfaces: [org.apache.royale.core.IBead,
>> org.apache.royale.core.IPanelModel] };
>>>>>
>>>>> Because the field names are not quoted, then in most output, the
>> field name "interfaces" is renamed and all code referencing this field is
>> renamed as well. This is good because it means that you don't have to
>> download the word "interfaces" once per-class. Instead of 10 characters, it
>> is usually one or two. 100 classes saves you about 900 bytes.
>>>>>
>>>>> However, it turns out that in Tour De Flex, the main app uses
>> Reflection and Reflection uses a quoted 'interfaces' string and thus, the
>> field name 'interfaces' in ROYALE_CLASS_INFO isn't renamed, but in most
>> modules "interfaces" is renamed since no other code in the module has a
>> quoted string for 'interfaces'. But that means that when a module loads,
>> the Language.is/as won't work since classes in the main app are using
>> "interfaces" but the classes in the module are using some short name.
>>>>>
>>>>> One solution is to always quote that field in the compiler output
>> and Language is/as so it doesn't get renamed, but that means that field
>> will never get renamed and you lose saving those bytes.
>>>>>
>>>>> Another is let folks figure out their own workarounds, by adding
>> some code that will prevent the renaming in the modules.
>>>>>
>>>>> Other ideas are welcome. I'm done for tonight.
>>>>>
>>>>> Thoughts?
>>>>> -Alex
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
Re: ROYALE_CLASS_INFO, renaming, modules, Objects
Posted by Carlos Rovira <ca...@apache.org>.
Hi,
I'm still not using modules. I left that for now until we complete the
first phase in our project, but will be using (hopefully) around February.
So right now we're only using minification, that seems not only to reduce
the size of the build, but release mode performs faster, and I think is
due, in part, to minify.
So, IMHO, as a user, I don't like A). Can't think of a solution, since is
not my zone of expertise, and sure you guys found a good solution after
all. Just want to say that as a user, is importante both things: have
modules (and hope we could link as well with routing like people do in
other current techs like React and Angular to get a powerful solution for
SPAs) and have minification, since IMO, the resultant js-release build has
many, many advantages, not only in performance and size but as well in
obfuscation, and for me is like our "binary output code".
Sorry to not be able to give any suggestion, but maybe as well an opinion
of use is as well valuable.
just my 2
El mar., 11 dic. 2018 a las 21:24, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Thinking about it more, -js-dynamic-access probably won't help. We don't
> want to compile our SWCs with that option on and thus turn off minification
> of these field names always if we can help it.
>
> Even a directive per occurrence won't help either. Whether a field name
> is renamed is still dependent on what other code is in the compilation.
>
> The problem is better described as trying to find a way to control what
> field names get renamed in more than one compilation, given that there is
> pre-transpiled code that allows renaming. When building modules, we
> already require using Closure Compiler options that output the renaming
> maps of the main app so that UIBase is given the same short name in all
> minifications. But there is no way to dictate that for field names as far
> as I can tell.
>
> -Alex
>
> On 12/11/18, 11:32 AM, "Harbs" <ha...@gmail.com> wrote:
>
> I vote for A.
>
> We can also do B which would require manually changing all access to
> brackets and quote all names in object literals.
>
> I might be nice to add some comment decorations to enable/disable
> -js-dynamic-access on a case-by-case basis, but I think it’s reasonable to
> have a global on/off requirement. I’m already doing this for a library I
> wrote which has a lot of dynamic data structures which does not survive
> minification and the results are fine.
>
> My $0.02,
> Harbs
>
> > On Dec 11, 2018, at 8:47 PM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >
> > IMO, some folks will want to rely on minification of object field
> names so save space. I think -js-dynamic-access blocks minification.
> >
> > So, to try to pose the problem another way, you can rely on
> minification object field names if you are building a single-js-file app,
> but as soon as you start using modules, things may break. So what should
> we tell folks?
> >
> > A) if you use modules you must turn off minification in objects with
> -js-dynamic-access
> > B) here are some ways to hack your code so you can still rely on
> minification
> > C) something else?
> >
> > We can manually rename fields in ROYALE_CLASS_INFO and other
> structures to make our code less readable in debug mode but save space in
> release mode, but that does not solve the general case problem. Folks may
> have other objects in their apps and modules that work until you add some
> code to one of the projects that changes which object fields get renamed.
> >
> > -Alex
> >
> > On 12/11/18, 9:31 AM, "Harbs" <ha...@gmail.com> wrote:
> >
> > I’m not following why this is the same point.
> >
> > I’m using -js-dynamic-access-unknown-members=true to handle this
> kind of problem. It works flawlessly…
> >
> > I’d personally argue that true should be the default, but whether
> the default is true or not, we do have an option to deal with these kinds
> of data structures.
> >
> >> On Dec 11, 2018, at 6:39 PM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >>
> >> Yes, we can use our own short names in code we generate, but that's
> not really the point.
> >>
> >> The point is that any plain object field can be renamed based on
> other code in the compile. So if you just have:
> >>
> >> Var obj:Object = { harbs: 1};
> >> Public static function foo()
> >> {
> >> Trace(obj.harbs);
> >> }
> >>
> >> Use of foo() in one compile may result in harbs being renamed, and
> another wouldn't. And that poses a problem when data structures are shared
> between compiled outputs.
> >>
> >> This is a natural way to write AS, but the JS results when minified
> and shared between app and modules can fail. So what restrictions should
> we place if any on how folks use plain objects?
> >>
> >> HTH,
> >> -Alex
> >>
> >> On 12/11/18, 7:36 AM, "Harbs" <ha...@gmail.com> wrote:
> >>
> >> I was about to make the same suggestion. We can use “I” for
> interfaces, “c” for class, “k” for kind, “n” for names. etc.
> >>
> >>> On Dec 11, 2018, at 2:52 PM, Frost, Andrew <An...@Harman.com>
> wrote:
> >>>
> >>> Hi
> >>>
> >>> Not sure that I fully understand this but would a valid compromise
> be something where the field name isn't renamed at all automatically, but
> we just change it in the JS generation code to be "i" rather than
> "interfaces", and update the Language is/as functions to work with this
> property name? Not sure whether it would work and I don't know whether the
> Reflection stuff would then need to change too, but if this is all in the
> generated outputs and/or the framework's own code then it shouldn't be
> something that the end user would bother about..
> >>>
> >>> thanks
> >>>
> >>> Andrew
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Alex Harui [mailto:aharui@adobe.com.INVALID]
> >>> Sent: 11 December 2018 08:32
> >>> To: dev@royale.apache.org
> >>> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules, Objects
> >>>
> >>> I spent some time today trying to get Tour De Flex to run in
> production mode with the main app and modules being separately minified.
> >>>
> >>> I've fixed a few things here and there, but an interesting issue I
> ran into has to do with the plain object we use in ROYALE_CLASS_INFO (and
> will apply to other objects).
> >>>
> >>> The ROYALE_CLASS_INFO is generated on each class and has a "names"
> property and an optional "interfaces" property. An example is:
> >>>
> >>>
> org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO
> = { names: [{ name: 'PanelModel', qName:
> 'org.apache.royale.html.beads.models.PanelModel', kind: 'class' }],
> interfaces: [org.apache.royale.core.IBead,
> org.apache.royale.core.IPanelModel] };
> >>>
> >>> Because the field names are not quoted, then in most output, the
> field name "interfaces" is renamed and all code referencing this field is
> renamed as well. This is good because it means that you don't have to
> download the word "interfaces" once per-class. Instead of 10 characters, it
> is usually one or two. 100 classes saves you about 900 bytes.
> >>>
> >>> However, it turns out that in Tour De Flex, the main app uses
> Reflection and Reflection uses a quoted 'interfaces' string and thus, the
> field name 'interfaces' in ROYALE_CLASS_INFO isn't renamed, but in most
> modules "interfaces" is renamed since no other code in the module has a
> quoted string for 'interfaces'. But that means that when a module loads,
> the Language.is/as won't work since classes in the main app are using
> "interfaces" but the classes in the module are using some short name.
> >>>
> >>> One solution is to always quote that field in the compiler output
> and Language is/as so it doesn't get renamed, but that means that field
> will never get renamed and you lose saving those bytes.
> >>>
> >>> Another is let folks figure out their own workarounds, by adding
> some code that will prevent the renaming in the modules.
> >>>
> >>> Other ideas are welcome. I'm done for tonight.
> >>>
> >>> Thoughts?
> >>> -Alex
> >>>
> >>
> >>
> >>
> >
> >
> >
>
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: ROYALE_CLASS_INFO, renaming, modules, Objects
Posted by Harbs <ha...@gmail.com>.
Shouldn’t we try an avoid use of dynamic objects in framework code?
> On Dec 11, 2018, at 10:23 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Thinking about it more, -js-dynamic-access probably won't help. We don't want to compile our SWCs with that option on and thus turn off minification of these field names always if we can help it.
>
> Even a directive per occurrence won't help either. Whether a field name is renamed is still dependent on what other code is in the compilation.
>
> The problem is better described as trying to find a way to control what field names get renamed in more than one compilation, given that there is pre-transpiled code that allows renaming. When building modules, we already require using Closure Compiler options that output the renaming maps of the main app so that UIBase is given the same short name in all minifications. But there is no way to dictate that for field names as far as I can tell.
>
> -Alex
>
> On 12/11/18, 11:32 AM, "Harbs" <ha...@gmail.com> wrote:
>
> I vote for A.
>
> We can also do B which would require manually changing all access to brackets and quote all names in object literals.
>
> I might be nice to add some comment decorations to enable/disable -js-dynamic-access on a case-by-case basis, but I think it’s reasonable to have a global on/off requirement. I’m already doing this for a library I wrote which has a lot of dynamic data structures which does not survive minification and the results are fine.
>
> My $0.02,
> Harbs
>
>> On Dec 11, 2018, at 8:47 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> IMO, some folks will want to rely on minification of object field names so save space. I think -js-dynamic-access blocks minification.
>>
>> So, to try to pose the problem another way, you can rely on minification object field names if you are building a single-js-file app, but as soon as you start using modules, things may break. So what should we tell folks?
>>
>> A) if you use modules you must turn off minification in objects with -js-dynamic-access
>> B) here are some ways to hack your code so you can still rely on minification
>> C) something else?
>>
>> We can manually rename fields in ROYALE_CLASS_INFO and other structures to make our code less readable in debug mode but save space in release mode, but that does not solve the general case problem. Folks may have other objects in their apps and modules that work until you add some code to one of the projects that changes which object fields get renamed.
>>
>> -Alex
>>
>> On 12/11/18, 9:31 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>> I’m not following why this is the same point.
>>
>> I’m using -js-dynamic-access-unknown-members=true to handle this kind of problem. It works flawlessly…
>>
>> I’d personally argue that true should be the default, but whether the default is true or not, we do have an option to deal with these kinds of data structures.
>>
>>> On Dec 11, 2018, at 6:39 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>
>>> Yes, we can use our own short names in code we generate, but that's not really the point.
>>>
>>> The point is that any plain object field can be renamed based on other code in the compile. So if you just have:
>>>
>>> Var obj:Object = { harbs: 1};
>>> Public static function foo()
>>> {
>>> Trace(obj.harbs);
>>> }
>>>
>>> Use of foo() in one compile may result in harbs being renamed, and another wouldn't. And that poses a problem when data structures are shared between compiled outputs.
>>>
>>> This is a natural way to write AS, but the JS results when minified and shared between app and modules can fail. So what restrictions should we place if any on how folks use plain objects?
>>>
>>> HTH,
>>> -Alex
>>>
>>> On 12/11/18, 7:36 AM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>> I was about to make the same suggestion. We can use “I” for interfaces, “c” for class, “k” for kind, “n” for names. etc.
>>>
>>>> On Dec 11, 2018, at 2:52 PM, Frost, Andrew <An...@Harman.com> wrote:
>>>>
>>>> Hi
>>>>
>>>> Not sure that I fully understand this but would a valid compromise be something where the field name isn't renamed at all automatically, but we just change it in the JS generation code to be "i" rather than "interfaces", and update the Language is/as functions to work with this property name? Not sure whether it would work and I don't know whether the Reflection stuff would then need to change too, but if this is all in the generated outputs and/or the framework's own code then it shouldn't be something that the end user would bother about..
>>>>
>>>> thanks
>>>>
>>>> Andrew
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Alex Harui [mailto:aharui@adobe.com.INVALID]
>>>> Sent: 11 December 2018 08:32
>>>> To: dev@royale.apache.org
>>>> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules, Objects
>>>>
>>>> I spent some time today trying to get Tour De Flex to run in production mode with the main app and modules being separately minified.
>>>>
>>>> I've fixed a few things here and there, but an interesting issue I ran into has to do with the plain object we use in ROYALE_CLASS_INFO (and will apply to other objects).
>>>>
>>>> The ROYALE_CLASS_INFO is generated on each class and has a "names" property and an optional "interfaces" property. An example is:
>>>>
>>>> org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO = { names: [{ name: 'PanelModel', qName: 'org.apache.royale.html.beads.models.PanelModel', kind: 'class' }], interfaces: [org.apache.royale.core.IBead, org.apache.royale.core.IPanelModel] };
>>>>
>>>> Because the field names are not quoted, then in most output, the field name "interfaces" is renamed and all code referencing this field is renamed as well. This is good because it means that you don't have to download the word "interfaces" once per-class. Instead of 10 characters, it is usually one or two. 100 classes saves you about 900 bytes.
>>>>
>>>> However, it turns out that in Tour De Flex, the main app uses Reflection and Reflection uses a quoted 'interfaces' string and thus, the field name 'interfaces' in ROYALE_CLASS_INFO isn't renamed, but in most modules "interfaces" is renamed since no other code in the module has a quoted string for 'interfaces'. But that means that when a module loads, the Language.is/as won't work since classes in the main app are using "interfaces" but the classes in the module are using some short name.
>>>>
>>>> One solution is to always quote that field in the compiler output and Language is/as so it doesn't get renamed, but that means that field will never get renamed and you lose saving those bytes.
>>>>
>>>> Another is let folks figure out their own workarounds, by adding some code that will prevent the renaming in the modules.
>>>>
>>>> Other ideas are welcome. I'm done for tonight.
>>>>
>>>> Thoughts?
>>>> -Alex
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
Re: ROYALE_CLASS_INFO, renaming, modules, Objects
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Thinking about it more, -js-dynamic-access probably won't help. We don't want to compile our SWCs with that option on and thus turn off minification of these field names always if we can help it.
Even a directive per occurrence won't help either. Whether a field name is renamed is still dependent on what other code is in the compilation.
The problem is better described as trying to find a way to control what field names get renamed in more than one compilation, given that there is pre-transpiled code that allows renaming. When building modules, we already require using Closure Compiler options that output the renaming maps of the main app so that UIBase is given the same short name in all minifications. But there is no way to dictate that for field names as far as I can tell.
-Alex
On 12/11/18, 11:32 AM, "Harbs" <ha...@gmail.com> wrote:
I vote for A.
We can also do B which would require manually changing all access to brackets and quote all names in object literals.
I might be nice to add some comment decorations to enable/disable -js-dynamic-access on a case-by-case basis, but I think it’s reasonable to have a global on/off requirement. I’m already doing this for a library I wrote which has a lot of dynamic data structures which does not survive minification and the results are fine.
My $0.02,
Harbs
> On Dec 11, 2018, at 8:47 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> IMO, some folks will want to rely on minification of object field names so save space. I think -js-dynamic-access blocks minification.
>
> So, to try to pose the problem another way, you can rely on minification object field names if you are building a single-js-file app, but as soon as you start using modules, things may break. So what should we tell folks?
>
> A) if you use modules you must turn off minification in objects with -js-dynamic-access
> B) here are some ways to hack your code so you can still rely on minification
> C) something else?
>
> We can manually rename fields in ROYALE_CLASS_INFO and other structures to make our code less readable in debug mode but save space in release mode, but that does not solve the general case problem. Folks may have other objects in their apps and modules that work until you add some code to one of the projects that changes which object fields get renamed.
>
> -Alex
>
> On 12/11/18, 9:31 AM, "Harbs" <ha...@gmail.com> wrote:
>
> I’m not following why this is the same point.
>
> I’m using -js-dynamic-access-unknown-members=true to handle this kind of problem. It works flawlessly…
>
> I’d personally argue that true should be the default, but whether the default is true or not, we do have an option to deal with these kinds of data structures.
>
>> On Dec 11, 2018, at 6:39 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> Yes, we can use our own short names in code we generate, but that's not really the point.
>>
>> The point is that any plain object field can be renamed based on other code in the compile. So if you just have:
>>
>> Var obj:Object = { harbs: 1};
>> Public static function foo()
>> {
>> Trace(obj.harbs);
>> }
>>
>> Use of foo() in one compile may result in harbs being renamed, and another wouldn't. And that poses a problem when data structures are shared between compiled outputs.
>>
>> This is a natural way to write AS, but the JS results when minified and shared between app and modules can fail. So what restrictions should we place if any on how folks use plain objects?
>>
>> HTH,
>> -Alex
>>
>> On 12/11/18, 7:36 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>> I was about to make the same suggestion. We can use “I” for interfaces, “c” for class, “k” for kind, “n” for names. etc.
>>
>>> On Dec 11, 2018, at 2:52 PM, Frost, Andrew <An...@Harman.com> wrote:
>>>
>>> Hi
>>>
>>> Not sure that I fully understand this but would a valid compromise be something where the field name isn't renamed at all automatically, but we just change it in the JS generation code to be "i" rather than "interfaces", and update the Language is/as functions to work with this property name? Not sure whether it would work and I don't know whether the Reflection stuff would then need to change too, but if this is all in the generated outputs and/or the framework's own code then it shouldn't be something that the end user would bother about..
>>>
>>> thanks
>>>
>>> Andrew
>>>
>>>
>>> -----Original Message-----
>>> From: Alex Harui [mailto:aharui@adobe.com.INVALID]
>>> Sent: 11 December 2018 08:32
>>> To: dev@royale.apache.org
>>> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules, Objects
>>>
>>> I spent some time today trying to get Tour De Flex to run in production mode with the main app and modules being separately minified.
>>>
>>> I've fixed a few things here and there, but an interesting issue I ran into has to do with the plain object we use in ROYALE_CLASS_INFO (and will apply to other objects).
>>>
>>> The ROYALE_CLASS_INFO is generated on each class and has a "names" property and an optional "interfaces" property. An example is:
>>>
>>> org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO = { names: [{ name: 'PanelModel', qName: 'org.apache.royale.html.beads.models.PanelModel', kind: 'class' }], interfaces: [org.apache.royale.core.IBead, org.apache.royale.core.IPanelModel] };
>>>
>>> Because the field names are not quoted, then in most output, the field name "interfaces" is renamed and all code referencing this field is renamed as well. This is good because it means that you don't have to download the word "interfaces" once per-class. Instead of 10 characters, it is usually one or two. 100 classes saves you about 900 bytes.
>>>
>>> However, it turns out that in Tour De Flex, the main app uses Reflection and Reflection uses a quoted 'interfaces' string and thus, the field name 'interfaces' in ROYALE_CLASS_INFO isn't renamed, but in most modules "interfaces" is renamed since no other code in the module has a quoted string for 'interfaces'. But that means that when a module loads, the Language.is/as won't work since classes in the main app are using "interfaces" but the classes in the module are using some short name.
>>>
>>> One solution is to always quote that field in the compiler output and Language is/as so it doesn't get renamed, but that means that field will never get renamed and you lose saving those bytes.
>>>
>>> Another is let folks figure out their own workarounds, by adding some code that will prevent the renaming in the modules.
>>>
>>> Other ideas are welcome. I'm done for tonight.
>>>
>>> Thoughts?
>>> -Alex
>>>
>>
>>
>>
>
>
>
Re: ROYALE_CLASS_INFO, renaming, modules, Objects
Posted by Harbs <ha...@gmail.com>.
I vote for A.
We can also do B which would require manually changing all access to brackets and quote all names in object literals.
I might be nice to add some comment decorations to enable/disable -js-dynamic-access on a case-by-case basis, but I think it’s reasonable to have a global on/off requirement. I’m already doing this for a library I wrote which has a lot of dynamic data structures which does not survive minification and the results are fine.
My $0.02,
Harbs
> On Dec 11, 2018, at 8:47 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> IMO, some folks will want to rely on minification of object field names so save space. I think -js-dynamic-access blocks minification.
>
> So, to try to pose the problem another way, you can rely on minification object field names if you are building a single-js-file app, but as soon as you start using modules, things may break. So what should we tell folks?
>
> A) if you use modules you must turn off minification in objects with -js-dynamic-access
> B) here are some ways to hack your code so you can still rely on minification
> C) something else?
>
> We can manually rename fields in ROYALE_CLASS_INFO and other structures to make our code less readable in debug mode but save space in release mode, but that does not solve the general case problem. Folks may have other objects in their apps and modules that work until you add some code to one of the projects that changes which object fields get renamed.
>
> -Alex
>
> On 12/11/18, 9:31 AM, "Harbs" <ha...@gmail.com> wrote:
>
> I’m not following why this is the same point.
>
> I’m using -js-dynamic-access-unknown-members=true to handle this kind of problem. It works flawlessly…
>
> I’d personally argue that true should be the default, but whether the default is true or not, we do have an option to deal with these kinds of data structures.
>
>> On Dec 11, 2018, at 6:39 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> Yes, we can use our own short names in code we generate, but that's not really the point.
>>
>> The point is that any plain object field can be renamed based on other code in the compile. So if you just have:
>>
>> Var obj:Object = { harbs: 1};
>> Public static function foo()
>> {
>> Trace(obj.harbs);
>> }
>>
>> Use of foo() in one compile may result in harbs being renamed, and another wouldn't. And that poses a problem when data structures are shared between compiled outputs.
>>
>> This is a natural way to write AS, but the JS results when minified and shared between app and modules can fail. So what restrictions should we place if any on how folks use plain objects?
>>
>> HTH,
>> -Alex
>>
>> On 12/11/18, 7:36 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>> I was about to make the same suggestion. We can use “I” for interfaces, “c” for class, “k” for kind, “n” for names. etc.
>>
>>> On Dec 11, 2018, at 2:52 PM, Frost, Andrew <An...@Harman.com> wrote:
>>>
>>> Hi
>>>
>>> Not sure that I fully understand this but would a valid compromise be something where the field name isn't renamed at all automatically, but we just change it in the JS generation code to be "i" rather than "interfaces", and update the Language is/as functions to work with this property name? Not sure whether it would work and I don't know whether the Reflection stuff would then need to change too, but if this is all in the generated outputs and/or the framework's own code then it shouldn't be something that the end user would bother about..
>>>
>>> thanks
>>>
>>> Andrew
>>>
>>>
>>> -----Original Message-----
>>> From: Alex Harui [mailto:aharui@adobe.com.INVALID]
>>> Sent: 11 December 2018 08:32
>>> To: dev@royale.apache.org
>>> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules, Objects
>>>
>>> I spent some time today trying to get Tour De Flex to run in production mode with the main app and modules being separately minified.
>>>
>>> I've fixed a few things here and there, but an interesting issue I ran into has to do with the plain object we use in ROYALE_CLASS_INFO (and will apply to other objects).
>>>
>>> The ROYALE_CLASS_INFO is generated on each class and has a "names" property and an optional "interfaces" property. An example is:
>>>
>>> org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO = { names: [{ name: 'PanelModel', qName: 'org.apache.royale.html.beads.models.PanelModel', kind: 'class' }], interfaces: [org.apache.royale.core.IBead, org.apache.royale.core.IPanelModel] };
>>>
>>> Because the field names are not quoted, then in most output, the field name "interfaces" is renamed and all code referencing this field is renamed as well. This is good because it means that you don't have to download the word "interfaces" once per-class. Instead of 10 characters, it is usually one or two. 100 classes saves you about 900 bytes.
>>>
>>> However, it turns out that in Tour De Flex, the main app uses Reflection and Reflection uses a quoted 'interfaces' string and thus, the field name 'interfaces' in ROYALE_CLASS_INFO isn't renamed, but in most modules "interfaces" is renamed since no other code in the module has a quoted string for 'interfaces'. But that means that when a module loads, the Language.is/as won't work since classes in the main app are using "interfaces" but the classes in the module are using some short name.
>>>
>>> One solution is to always quote that field in the compiler output and Language is/as so it doesn't get renamed, but that means that field will never get renamed and you lose saving those bytes.
>>>
>>> Another is let folks figure out their own workarounds, by adding some code that will prevent the renaming in the modules.
>>>
>>> Other ideas are welcome. I'm done for tonight.
>>>
>>> Thoughts?
>>> -Alex
>>>
>>
>>
>>
>
>
>
Re: ROYALE_CLASS_INFO, renaming, modules, Objects
Posted by Alex Harui <ah...@adobe.com.INVALID>.
IMO, some folks will want to rely on minification of object field names so save space. I think -js-dynamic-access blocks minification.
So, to try to pose the problem another way, you can rely on minification object field names if you are building a single-js-file app, but as soon as you start using modules, things may break. So what should we tell folks?
A) if you use modules you must turn off minification in objects with -js-dynamic-access
B) here are some ways to hack your code so you can still rely on minification
C) something else?
We can manually rename fields in ROYALE_CLASS_INFO and other structures to make our code less readable in debug mode but save space in release mode, but that does not solve the general case problem. Folks may have other objects in their apps and modules that work until you add some code to one of the projects that changes which object fields get renamed.
-Alex
On 12/11/18, 9:31 AM, "Harbs" <ha...@gmail.com> wrote:
I’m not following why this is the same point.
I’m using -js-dynamic-access-unknown-members=true to handle this kind of problem. It works flawlessly…
I’d personally argue that true should be the default, but whether the default is true or not, we do have an option to deal with these kinds of data structures.
> On Dec 11, 2018, at 6:39 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Yes, we can use our own short names in code we generate, but that's not really the point.
>
> The point is that any plain object field can be renamed based on other code in the compile. So if you just have:
>
> Var obj:Object = { harbs: 1};
> Public static function foo()
> {
> Trace(obj.harbs);
> }
>
> Use of foo() in one compile may result in harbs being renamed, and another wouldn't. And that poses a problem when data structures are shared between compiled outputs.
>
> This is a natural way to write AS, but the JS results when minified and shared between app and modules can fail. So what restrictions should we place if any on how folks use plain objects?
>
> HTH,
> -Alex
>
> On 12/11/18, 7:36 AM, "Harbs" <ha...@gmail.com> wrote:
>
> I was about to make the same suggestion. We can use “I” for interfaces, “c” for class, “k” for kind, “n” for names. etc.
>
>> On Dec 11, 2018, at 2:52 PM, Frost, Andrew <An...@Harman.com> wrote:
>>
>> Hi
>>
>> Not sure that I fully understand this but would a valid compromise be something where the field name isn't renamed at all automatically, but we just change it in the JS generation code to be "i" rather than "interfaces", and update the Language is/as functions to work with this property name? Not sure whether it would work and I don't know whether the Reflection stuff would then need to change too, but if this is all in the generated outputs and/or the framework's own code then it shouldn't be something that the end user would bother about..
>>
>> thanks
>>
>> Andrew
>>
>>
>> -----Original Message-----
>> From: Alex Harui [mailto:aharui@adobe.com.INVALID]
>> Sent: 11 December 2018 08:32
>> To: dev@royale.apache.org
>> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules, Objects
>>
>> I spent some time today trying to get Tour De Flex to run in production mode with the main app and modules being separately minified.
>>
>> I've fixed a few things here and there, but an interesting issue I ran into has to do with the plain object we use in ROYALE_CLASS_INFO (and will apply to other objects).
>>
>> The ROYALE_CLASS_INFO is generated on each class and has a "names" property and an optional "interfaces" property. An example is:
>>
>> org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO = { names: [{ name: 'PanelModel', qName: 'org.apache.royale.html.beads.models.PanelModel', kind: 'class' }], interfaces: [org.apache.royale.core.IBead, org.apache.royale.core.IPanelModel] };
>>
>> Because the field names are not quoted, then in most output, the field name "interfaces" is renamed and all code referencing this field is renamed as well. This is good because it means that you don't have to download the word "interfaces" once per-class. Instead of 10 characters, it is usually one or two. 100 classes saves you about 900 bytes.
>>
>> However, it turns out that in Tour De Flex, the main app uses Reflection and Reflection uses a quoted 'interfaces' string and thus, the field name 'interfaces' in ROYALE_CLASS_INFO isn't renamed, but in most modules "interfaces" is renamed since no other code in the module has a quoted string for 'interfaces'. But that means that when a module loads, the Language.is/as won't work since classes in the main app are using "interfaces" but the classes in the module are using some short name.
>>
>> One solution is to always quote that field in the compiler output and Language is/as so it doesn't get renamed, but that means that field will never get renamed and you lose saving those bytes.
>>
>> Another is let folks figure out their own workarounds, by adding some code that will prevent the renaming in the modules.
>>
>> Other ideas are welcome. I'm done for tonight.
>>
>> Thoughts?
>> -Alex
>>
>
>
>
Re: ROYALE_CLASS_INFO, renaming, modules, Objects
Posted by Harbs <ha...@gmail.com>.
I’m not following why this is the same point.
I’m using -js-dynamic-access-unknown-members=true to handle this kind of problem. It works flawlessly…
I’d personally argue that true should be the default, but whether the default is true or not, we do have an option to deal with these kinds of data structures.
> On Dec 11, 2018, at 6:39 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Yes, we can use our own short names in code we generate, but that's not really the point.
>
> The point is that any plain object field can be renamed based on other code in the compile. So if you just have:
>
> Var obj:Object = { harbs: 1};
> Public static function foo()
> {
> Trace(obj.harbs);
> }
>
> Use of foo() in one compile may result in harbs being renamed, and another wouldn't. And that poses a problem when data structures are shared between compiled outputs.
>
> This is a natural way to write AS, but the JS results when minified and shared between app and modules can fail. So what restrictions should we place if any on how folks use plain objects?
>
> HTH,
> -Alex
>
> On 12/11/18, 7:36 AM, "Harbs" <ha...@gmail.com> wrote:
>
> I was about to make the same suggestion. We can use “I” for interfaces, “c” for class, “k” for kind, “n” for names. etc.
>
>> On Dec 11, 2018, at 2:52 PM, Frost, Andrew <An...@Harman.com> wrote:
>>
>> Hi
>>
>> Not sure that I fully understand this but would a valid compromise be something where the field name isn't renamed at all automatically, but we just change it in the JS generation code to be "i" rather than "interfaces", and update the Language is/as functions to work with this property name? Not sure whether it would work and I don't know whether the Reflection stuff would then need to change too, but if this is all in the generated outputs and/or the framework's own code then it shouldn't be something that the end user would bother about..
>>
>> thanks
>>
>> Andrew
>>
>>
>> -----Original Message-----
>> From: Alex Harui [mailto:aharui@adobe.com.INVALID]
>> Sent: 11 December 2018 08:32
>> To: dev@royale.apache.org
>> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules, Objects
>>
>> I spent some time today trying to get Tour De Flex to run in production mode with the main app and modules being separately minified.
>>
>> I've fixed a few things here and there, but an interesting issue I ran into has to do with the plain object we use in ROYALE_CLASS_INFO (and will apply to other objects).
>>
>> The ROYALE_CLASS_INFO is generated on each class and has a "names" property and an optional "interfaces" property. An example is:
>>
>> org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO = { names: [{ name: 'PanelModel', qName: 'org.apache.royale.html.beads.models.PanelModel', kind: 'class' }], interfaces: [org.apache.royale.core.IBead, org.apache.royale.core.IPanelModel] };
>>
>> Because the field names are not quoted, then in most output, the field name "interfaces" is renamed and all code referencing this field is renamed as well. This is good because it means that you don't have to download the word "interfaces" once per-class. Instead of 10 characters, it is usually one or two. 100 classes saves you about 900 bytes.
>>
>> However, it turns out that in Tour De Flex, the main app uses Reflection and Reflection uses a quoted 'interfaces' string and thus, the field name 'interfaces' in ROYALE_CLASS_INFO isn't renamed, but in most modules "interfaces" is renamed since no other code in the module has a quoted string for 'interfaces'. But that means that when a module loads, the Language.is/as won't work since classes in the main app are using "interfaces" but the classes in the module are using some short name.
>>
>> One solution is to always quote that field in the compiler output and Language is/as so it doesn't get renamed, but that means that field will never get renamed and you lose saving those bytes.
>>
>> Another is let folks figure out their own workarounds, by adding some code that will prevent the renaming in the modules.
>>
>> Other ideas are welcome. I'm done for tonight.
>>
>> Thoughts?
>> -Alex
>>
>
>
>
Re: ROYALE_CLASS_INFO, renaming, modules, Objects
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Yes, we can use our own short names in code we generate, but that's not really the point.
The point is that any plain object field can be renamed based on other code in the compile. So if you just have:
Var obj:Object = { harbs: 1};
Public static function foo()
{
Trace(obj.harbs);
}
Use of foo() in one compile may result in harbs being renamed, and another wouldn't. And that poses a problem when data structures are shared between compiled outputs.
This is a natural way to write AS, but the JS results when minified and shared between app and modules can fail. So what restrictions should we place if any on how folks use plain objects?
HTH,
-Alex
On 12/11/18, 7:36 AM, "Harbs" <ha...@gmail.com> wrote:
I was about to make the same suggestion. We can use “I” for interfaces, “c” for class, “k” for kind, “n” for names. etc.
> On Dec 11, 2018, at 2:52 PM, Frost, Andrew <An...@Harman.com> wrote:
>
> Hi
>
> Not sure that I fully understand this but would a valid compromise be something where the field name isn't renamed at all automatically, but we just change it in the JS generation code to be "i" rather than "interfaces", and update the Language is/as functions to work with this property name? Not sure whether it would work and I don't know whether the Reflection stuff would then need to change too, but if this is all in the generated outputs and/or the framework's own code then it shouldn't be something that the end user would bother about..
>
> thanks
>
> Andrew
>
>
> -----Original Message-----
> From: Alex Harui [mailto:aharui@adobe.com.INVALID]
> Sent: 11 December 2018 08:32
> To: dev@royale.apache.org
> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules, Objects
>
> I spent some time today trying to get Tour De Flex to run in production mode with the main app and modules being separately minified.
>
> I've fixed a few things here and there, but an interesting issue I ran into has to do with the plain object we use in ROYALE_CLASS_INFO (and will apply to other objects).
>
> The ROYALE_CLASS_INFO is generated on each class and has a "names" property and an optional "interfaces" property. An example is:
>
> org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO = { names: [{ name: 'PanelModel', qName: 'org.apache.royale.html.beads.models.PanelModel', kind: 'class' }], interfaces: [org.apache.royale.core.IBead, org.apache.royale.core.IPanelModel] };
>
> Because the field names are not quoted, then in most output, the field name "interfaces" is renamed and all code referencing this field is renamed as well. This is good because it means that you don't have to download the word "interfaces" once per-class. Instead of 10 characters, it is usually one or two. 100 classes saves you about 900 bytes.
>
> However, it turns out that in Tour De Flex, the main app uses Reflection and Reflection uses a quoted 'interfaces' string and thus, the field name 'interfaces' in ROYALE_CLASS_INFO isn't renamed, but in most modules "interfaces" is renamed since no other code in the module has a quoted string for 'interfaces'. But that means that when a module loads, the Language.is/as won't work since classes in the main app are using "interfaces" but the classes in the module are using some short name.
>
> One solution is to always quote that field in the compiler output and Language is/as so it doesn't get renamed, but that means that field will never get renamed and you lose saving those bytes.
>
> Another is let folks figure out their own workarounds, by adding some code that will prevent the renaming in the modules.
>
> Other ideas are welcome. I'm done for tonight.
>
> Thoughts?
> -Alex
>
Re: ROYALE_CLASS_INFO, renaming, modules, Objects
Posted by Harbs <ha...@gmail.com>.
I was about to make the same suggestion. We can use “I” for interfaces, “c” for class, “k” for kind, “n” for names. etc.
> On Dec 11, 2018, at 2:52 PM, Frost, Andrew <An...@Harman.com> wrote:
>
> Hi
>
> Not sure that I fully understand this but would a valid compromise be something where the field name isn't renamed at all automatically, but we just change it in the JS generation code to be "i" rather than "interfaces", and update the Language is/as functions to work with this property name? Not sure whether it would work and I don't know whether the Reflection stuff would then need to change too, but if this is all in the generated outputs and/or the framework's own code then it shouldn't be something that the end user would bother about..
>
> thanks
>
> Andrew
>
>
> -----Original Message-----
> From: Alex Harui [mailto:aharui@adobe.com.INVALID]
> Sent: 11 December 2018 08:32
> To: dev@royale.apache.org
> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules, Objects
>
> I spent some time today trying to get Tour De Flex to run in production mode with the main app and modules being separately minified.
>
> I've fixed a few things here and there, but an interesting issue I ran into has to do with the plain object we use in ROYALE_CLASS_INFO (and will apply to other objects).
>
> The ROYALE_CLASS_INFO is generated on each class and has a "names" property and an optional "interfaces" property. An example is:
>
> org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO = { names: [{ name: 'PanelModel', qName: 'org.apache.royale.html.beads.models.PanelModel', kind: 'class' }], interfaces: [org.apache.royale.core.IBead, org.apache.royale.core.IPanelModel] };
>
> Because the field names are not quoted, then in most output, the field name "interfaces" is renamed and all code referencing this field is renamed as well. This is good because it means that you don't have to download the word "interfaces" once per-class. Instead of 10 characters, it is usually one or two. 100 classes saves you about 900 bytes.
>
> However, it turns out that in Tour De Flex, the main app uses Reflection and Reflection uses a quoted 'interfaces' string and thus, the field name 'interfaces' in ROYALE_CLASS_INFO isn't renamed, but in most modules "interfaces" is renamed since no other code in the module has a quoted string for 'interfaces'. But that means that when a module loads, the Language.is/as won't work since classes in the main app are using "interfaces" but the classes in the module are using some short name.
>
> One solution is to always quote that field in the compiler output and Language is/as so it doesn't get renamed, but that means that field will never get renamed and you lose saving those bytes.
>
> Another is let folks figure out their own workarounds, by adding some code that will prevent the renaming in the modules.
>
> Other ideas are welcome. I'm done for tonight.
>
> Thoughts?
> -Alex
>
RE: ROYALE_CLASS_INFO, renaming, modules, Objects
Posted by "Frost, Andrew" <An...@Harman.com>.
Hi
Not sure that I fully understand this but would a valid compromise be something where the field name isn't renamed at all automatically, but we just change it in the JS generation code to be "i" rather than "interfaces", and update the Language is/as functions to work with this property name? Not sure whether it would work and I don't know whether the Reflection stuff would then need to change too, but if this is all in the generated outputs and/or the framework's own code then it shouldn't be something that the end user would bother about..
thanks
Andrew
-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com.INVALID]
Sent: 11 December 2018 08:32
To: dev@royale.apache.org
Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules, Objects
I spent some time today trying to get Tour De Flex to run in production mode with the main app and modules being separately minified.
I've fixed a few things here and there, but an interesting issue I ran into has to do with the plain object we use in ROYALE_CLASS_INFO (and will apply to other objects).
The ROYALE_CLASS_INFO is generated on each class and has a "names" property and an optional "interfaces" property. An example is:
org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO = { names: [{ name: 'PanelModel', qName: 'org.apache.royale.html.beads.models.PanelModel', kind: 'class' }], interfaces: [org.apache.royale.core.IBead, org.apache.royale.core.IPanelModel] };
Because the field names are not quoted, then in most output, the field name "interfaces" is renamed and all code referencing this field is renamed as well. This is good because it means that you don't have to download the word "interfaces" once per-class. Instead of 10 characters, it is usually one or two. 100 classes saves you about 900 bytes.
However, it turns out that in Tour De Flex, the main app uses Reflection and Reflection uses a quoted 'interfaces' string and thus, the field name 'interfaces' in ROYALE_CLASS_INFO isn't renamed, but in most modules "interfaces" is renamed since no other code in the module has a quoted string for 'interfaces'. But that means that when a module loads, the Language.is/as won't work since classes in the main app are using "interfaces" but the classes in the module are using some short name.
One solution is to always quote that field in the compiler output and Language is/as so it doesn't get renamed, but that means that field will never get renamed and you lose saving those bytes.
Another is let folks figure out their own workarounds, by adding some code that will prevent the renaming in the modules.
Other ideas are welcome. I'm done for tonight.
Thoughts?
-Alex