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
>>
>
>
>
