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