Hi Alex,
it seems to me the perfect solution. To have that contract through
interfaces and using getters/setters is almost all you should need to
separate app from modules and just have a tiny layer of code to tie all,
while continue to work the minified version.
Thanks for working on that
El mié., 12 dic. 2018 a las 1:56, Alex Harui (<aha...@adobe.com.invalid>)
escribió:
> FWIW, I found one way to force the minifier to not rename a property,
> which is to create a getter of that name. I tried creating other object
> structures but they didn't work. So the implementation I am testing right
> now is that Module and ModuleLoader have these extra getters to guarantee
> that ROYALE_CLASS_INFO doesn't get renamed in one compilation but not the
> other. That seems PAYG as the cost is paid when you use modules.
>
> Anyone who wants to dig further for a better way to control renaming is
> welcome.
>
> Thanks,
> -Alex
>
> On 12/11/18, 2:33 PM, "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 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 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> 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>> 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>
> 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> 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>)
> >>> 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> 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
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> --
> >>> Carlos Rovira
> >>>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cd633bd078e4b49dffef008d65fb89f4c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636801643904081218&sdata=qQ9i5ZVGLKLvJimX2KhDJOEGPdywq5Ske7IAMGcO2Xo%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cd633bd078e4b49dffef008d65fb89f4c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636801643904081218&sdata=qQ9i5ZVGLKLvJimX2KhDJOEGPdywq5Ske7IAMGcO2Xo%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
