Using a plain object allows renaming. Using a class definition prevents
renaming.
Using shortnames in plain objects prevents renaming but is, IMO, a bad
practice. Why make our code harder to read? It isn't just in the data
structure, but in the code that reads it.
-Alex
On 12/12/18, 2:34 AM, "Carlos Rovira" <carlos.rov...@codeoscopic.com> wrote:
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
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flanguage.is%2F&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925068534&sdata=5VGfoczFg35bUnerVM144kIlrvfXuWd5m%2BpetEW%2FY74%3D&reserved=0>
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 <
>
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flanguage.is%2F&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=zsy%2FoU9vn%2BoGUd5Ri57fHeqW5wbzhqvo1lXlgZWwkCY%3D&reserved=0>
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
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flanguage.is%2Fas&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=o%2FC8K1KRrYdkwLuQfkLG3tU2AlVRLGlaShPm37U5p8s%3D&reserved=0>
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%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=MnCmCfYt2uepmueMxwDcMFE0Ah60sJxFa7Kg2wBTa00%3D&reserved=0
> <
>
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=MnCmCfYt2uepmueMxwDcMFE0Ah60sJxFa7Kg2wBTa00%3D&reserved=0
> ><
>
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=MnCmCfYt2uepmueMxwDcMFE0Ah60sJxFa7Kg2wBTa00%3D&reserved=0
> <
>
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=MnCmCfYt2uepmueMxwDcMFE0Ah60sJxFa7Kg2wBTa00%3D&reserved=0
> >>
>
>
--
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=eT5WhToYF5NCxjWsGbIWaLx86wBOUDg%2B%2BCjgct9XJr4%3D&reserved=0>
Carlos Rovira
Presidente Ejecutivo
M: +34 607 22 60 05
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=eT5WhToYF5NCxjWsGbIWaLx86wBOUDg%2B%2BCjgct9XJr4%3D&reserved=0
Conócenos en 1 minuto!
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favant2.es%2F%23video&data=02%7C01%7Caharui%40adobe.com%7C4b2c1a1de33f4e2e61fa08d6601d7271%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802076925078539&sdata=HCsi5N6f87s7jX04eVfmVGT0J1IlGJ823VaKDSxHCbo%3D&reserved=0>
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
