Shouldn’t we try an avoid use of dynamic objects in framework code?
> On Dec 11, 2018, at 10:23 PM, Alex Harui <aha...@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" <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
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
