Hi Alex,
what do you mean with "prevent renaming"? there's some process that
implies a renaming? and renaming of what? the nested properties?
thanks
El mié., 12 dic. 2018 a las 17:21, Alex Harui (<aha...@adobe.com.invalid>)
escribió:
> 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
>
>
>
--
<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
