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.li...@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 <carlosrov...@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 (<aha...@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.li...@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 <aha...@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.li...@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 <aha...@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.li...@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.fr...@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:aha...@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
>
