Harb, That seems ok, but moreover...why don't we have a class definition instead a plain object, somethings like RoyaleClassInfo.as? Since Royale tries to enforce typing, I think using a plain object for royale class info, doesn't seems the most proper way to me
thanks El mié., 12 dic. 2018 a las 11:23, Harbs (<harbs.li...@gmail.com>) escribió: > Right, but I thought we already suggested single character names for the > ROYALE_CLASS_INFO object. > > To take one example: > org.apache.royale.html.supportClasses.Viewport.prototype.ROYALE_CLASS_INFO > = { names: [{ name: 'Viewport', qName: > 'org.apache.royale.html.supportClasses.Viewport', kind: 'class' }], > interfaces: [org.apache.royale.core.IBead, > org.apache.royale.core.IViewport] }; > > That would become: > org.apache.royale.html.supportClasses.Viewport.prototype.ROYALE_CLASS_INFO > = { n: [{ n: 'Viewport', q: > 'org.apache.royale.html.supportClasses.Viewport', k: 'class' }], i: > [org.apache.royale.core.IBead, org.apache.royale.core.IViewport] }; > > I’m pretty sure that’s enough to prevent renaming (because the closure > compiler does not rename single character variable names). If I’m wrong, we > could always output something like this: > > org.apache.royale.html.supportClasses.Viewport.prototype.ROYALE_CLASS_INFO > = { 'n': [{ 'n': 'Viewport', 'q': > 'org.apache.royale.html.supportClasses.Viewport', 'k': 'class' }], 'i': > [org.apache.royale.core.IBead, org.apache.royale.core.IViewport] }; > > Am I missing something? > Harbs > > > On Dec 12, 2018, at 12:32 AM, Alex Harui <aha...@adobe.com.INVALID> > wrote: > > > > ROYALE_CLASS_INFO is a dynamic object. There is no class definition for > it, which means that its field names can be renamed. > > > > The whole point of modules is to load classes that aren't in the main > app so that the main app loads faster. So, if you have > > > > MainApp.mxml > > <mx:Application> > > <mx:ModuleLoader url="MyModule" /> > > </mx:Application> > > > > MyModule.mxml > > <mx:Module> > > </mx:Module> > > > > The Language.is <http://language.is/> function linked into Main app > might be checking for ROYALE_CLASS_INFO.interfaces and Application class > will have a ROYALE_CLASS_INFO.interfaces property. But Module might have > ROYALE_CLASS_INFO.i instead of interfaces. And thus Language.is < > http://language.is/> will not work on classes in the module. It depends > on what other code is in the main app. It appears that use of > Reflection.SWC's TypeDefinition in the main app tells the minifier to not > minify the "interfaces" property. Which means that any code an app > developer might add to the app could change the minification of > ROYALE_CLASS_INFO, or any other dynamic object. > > > > I'm trying to figure out why the minifier thinks the use of "interfaces" > in TypeDefinition matters but other attempts I've tried to force the > minifier to not rename "interfaces" in the module have not worked. > > > > HTH, > > -Alex > > > > On 12/11/18, 2:19 PM, "Harbs" <harbs.li...@gmail.com <mailto: > harbs.li...@gmail.com>> wrote: > > > > I’m still not getting the connection to ROYALE_CLASS_INFO. > > > > Can you explain to me in pseudo-code the problem with that? Why does > a dynamic object have ROYALE_CLASS_INFO at all? > > > >> On Dec 12, 2018, at 12:16 AM, Alex Harui <aha...@adobe.com.INVALID> > wrote: > >> > >> I'm not sure why you think it is theoretical. For sure, in TDF, the > module is not loading because ROYALE_CLASS_INFO is minified differently in > the main app than the module. Any dynamic objects shared across > compilations are at risk of being renamed differently. I'm chasing down a > way to control it. > >> > >> We do have control over the names of classes and properties to > guarantee they are the same in the app and module. It is just these > dynamic object keys that we don't yet have control over. > >> > >> We do have the option of defining a class for ROYALE_CLASS_INFO, but > then it will never minify. I like the fact that it can minify without us > having to use shortnames. It makes our debug code more readable and > doesn't waste space in small apps. Adding a class definition for > ROYALE_CLASS_INFO would further add overhead to small apps. > >> > >> My 2 cents, > >> -Alex > >> > >> On 12/11/18, 2:06 PM, "Harbs" <harbs.li...@gmail.com <mailto: > harbs.li...@gmail.com> <mailto:harbs.li...@gmail.com <mailto: > harbs.li...@gmail.com>>> wrote: > >> > >> In fact, in looking through the framework code so far, the only place > I’ve found variable names not quoted (in JS compatible code) so far was in > CSSUtils where we have a colorMap. I’m pretty sure the colorMap will not > work after minification because the color names will not match… > >> > >>> On Dec 12, 2018, at 12:01 AM, Harbs <harbs.li...@gmail.com <mailto: > harbs.li...@gmail.com>> wrote: > >>> > >>> Hi Carlos, > >>> > >>> We’re only discussing dynamic objects. How many of those do you have > in your applications? I doubt there’s much difference in performance due to > minification of dynamic objects. > >>> > >>> In *all* our framework code we have dynamic object instantiation in > 435 places including TLF, Spark and MX classes. Without those packages, I’m > estimating it’s a small fraction of that and probably most of the dynamic > objects are hash maps where they don’t benefit from minification anyway. > >>> > >>> The vast majority of the cases where you’re using dynamic objects in > production code you don’t want the names minified either (i.e. API calls > and uses of JSON). > >>> > >>> I think that most of this discussion is more theoretical than > practical considerations. > >>> > >>> My $0.02, > >>> Harbs > >>> > >>>> On Dec 11, 2018, at 11:26 PM, Carlos Rovira <carlosrov...@apache.org > <mailto:carlosrov...@apache.org>> wrote: > >>>> > >>>> Hi, > >>>> > >>>> I'm still not using modules. I left that for now until we complete the > >>>> first phase in our project, but will be using (hopefully) around > February. > >>>> > >>>> So right now we're only using minification, that seems not only to > reduce > >>>> the size of the build, but release mode performs faster, and I think > is > >>>> due, in part, to minify. > >>>> > >>>> So, IMHO, as a user, I don't like A). Can't think of a solution, > since is > >>>> not my zone of expertise, and sure you guys found a good solution > after > >>>> all. Just want to say that as a user, is importante both things: have > >>>> modules (and hope we could link as well with routing like people do in > >>>> other current techs like React and Angular to get a powerful solution > for > >>>> SPAs) and have minification, since IMO, the resultant js-release > build has > >>>> many, many advantages, not only in performance and size but as well in > >>>> obfuscation, and for me is like our "binary output code". > >>>> > >>>> Sorry to not be able to give any suggestion, but maybe as well an > opinion > >>>> of use is as well valuable. > >>>> > >>>> just my 2 > >>>> > >>>> > >>>> El mar., 11 dic. 2018 a las 21:24, Alex Harui > (<aha...@adobe.com.invalid <mailto:aha...@adobe.com.invalid>>) > >>>> escribió: > >>>> > >>>>> 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 <mailto: > 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 > <mailto: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 <mailto: > 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 > <mailto: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 <mailto: > 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 <mailto: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 <mailto: > aha...@adobe.com.INVALID>] > >>>>>>>> Sent: 11 December 2018 08:32 > >>>>>>>> To: dev@royale.apache.org <mailto: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 <http://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 > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> -- > >>>> Carlos Rovira > >>>> > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2c36443f61b4436324ee08d65fb6a252%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636801635412696785&sdata=DwG2KMwX7oKIaag1NeuP%2BnNwPp4VD7amvdLaKmPQ7H8%3D&reserved=0 > < > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2c36443f61b4436324ee08d65fb6a252%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636801635412696785&sdata=DwG2KMwX7oKIaag1NeuP%2BnNwPp4VD7amvdLaKmPQ7H8%3D&reserved=0 > >< > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2c36443f61b4436324ee08d65fb6a252%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636801635412696785&sdata=DwG2KMwX7oKIaag1NeuP%2BnNwPp4VD7amvdLaKmPQ7H8%3D&reserved=0 > < > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2c36443f61b4436324ee08d65fb6a252%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636801635412696785&sdata=DwG2KMwX7oKIaag1NeuP%2BnNwPp4VD7amvdLaKmPQ7H8%3D&reserved=0 > >> > > -- <http://www.codeoscopic.com> Carlos Rovira Presidente Ejecutivo M: +34 607 22 60 05 http://www.codeoscopic.com Conócenos en 1 minuto! <https://avant2.es/#video> AVISO LEGAL: La información contenida en este correo electrónico, y en su caso en los documentos adjuntos, es información privilegiada para uso exclusivo de la persona y/o personas a las que va dirigido. No está permitido el acceso a este mensaje a cualquier otra persona distinta a los indicados. Si Usted no es uno de los destinatarios, cualquier duplicación, reproducción, distribución, así como cualquier uso de la información contenida en él o cualquiera otra acción u omisión tomada en relación con el mismo, está prohibida y puede ser ilegal. En dicho caso, por favor, notifíquelo al remitente y proceda a la eliminación de este correo electrónico, así como de sus adjuntos si los hubiere. En cumplimiento de la legislación española vigente en materia de protección de datos de carácter personal y del RGPD 679/2016 le informamos que sus datos están siendo objeto de tratamiento por parte de CODEOSCOPIC S.A. con CIFA85677342, con la finalidad del mantenimiento y gestión de relaciones comerciales y administrativas. La base jurídica del tratamiento es el interés legítimo de la empresa. No se prevén cesiones de sus datos, salvo que exista una obligación legal. Para ejercitar sus derechos puede dirigirse a CODEOSCOPIC S.A., domiciliada enPaseo de la Habana, 9-11, 28036 de Madrid (MADRID), o bien por email a...@codeoscopic.com, con el fin de ejercer sus derechos de acceso, rectificación, supresión (derecho al olvido), limitación de tratamiento, portabilidad de los datos, oposición, y a no ser objeto de decisiones automatizadas, indicando como Asunto: “Derechos Ley Protección de Datos”, y adjuntando fotocopia de su DNI. Delegado de protección de datos:d...@codeoscopic.com