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