I’m pretty sure that any names which are a single character (or I think two characters), will not be renamed by the google compiler.
> On Dec 11, 2018, at 11:19 PM, Frost, Andrew <andrew.fr...@harman.com> wrote: > > So I think what you're saying is that the full build process will result in a > minified JS file where e.g. a class with a property called "interfaces" might > be changed to "a"; but if we build another module then the minified JS file > may have changed the same "interfaces" property into "b"...? hence they're > incompatible? > > If option A works then it sounds good.. > I don’t know exactly how this is doing it, but a quick look at "Uglify" seems > to suggest that this is a problem that's been found/solved before: > https://www.npmjs.com/package/uglify-js > has the following note: > When you compress multiple files using this option, in order for them to work > together in the end we need to ensure somehow that one property gets mangled > to the same name in all of them. For this, pass --name-cache filename.json > and UglifyJS will maintain these mappings in a file which can then be reused. > > So that would seem to be the ideal option, so that we can have the > compression/minification still but ensuring that everything works together. > > Although, just looking at the Google Closure Compiler, perhaps they've not > actually got suitable solutions for these issues... > https://developers.google.com/closure/compiler/docs/api-tutorial3 has got > sections: > Inconsistent Property Names > and > Compiling Two Portions of Code Separately > neither of which have very practical solutions from our perspective :-( > > So turning off this level of optimization, when compiling multiple modules, > may be the only solution..? > > cheers > > Andrew > > > -----Original Message----- > From: Alex Harui [mailto:aha...@adobe.com.INVALID] > Sent: 11 December 2018 20:24 > To: dev@royale.apache.org > Subject: [EXTERNAL] Re: ROYALE_CLASS_INFO, renaming, modules, Objects > > 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 >>>> >>> >>> >>> >> >> >> > > >
