Alex, the compiler change you made recently for some things to 'prevent
renaming' for modules may require changes in related support classes in the
framework. I had to make a change in ClassAliasBead to have it continue to
work in release mode. I did that to get it working again because we are
using it and I could verify, but I see now that JSONReviver will likely
need the same change. I'm not using that so not in a position to verify it
and others. You probably know all the locations well in the framework that
relate to the compiler changes and I'm guessing you are in a better
position to test them (because I only used the alias stuff so far)... just
letting you know in case they may need the same treatment...
On Thu, Dec 13, 2018 at 2:11 PM Alex Harui <aha...@adobe.com.invalid> wrote:
> Closure Compiler will rename (to a short name) any object and property on
> any object that isn't marked as "don’t rename" via several techniques:
>
> 1) Externs
> 2) @export
> 3) bracket syntax (i.e. obj["dontRenameThisProperty"])
> 4) having a getter and/or setter of the same name elsewhere in the
> compilation
>
> By default, all Royale public and protected properties are marked as
> @export so they will never be renamed. That's what you want when
> deserializing network data or when folks might be using bracket syntax to
> access properties.
>
> It "should be" ok for us and others to use plain objects than can be
> minified/renamed if needed. The key is being able to control what gets
> minified. I think #4 gives a way to control it.
>
> HTH,
> -Alex
>
> On 12/12/18, 9:10 AM, "Carlos Rovira" <carlos.rov...@codeoscopic.com>
> wrote:
>
> 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%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=qSasD0ckW6c6zl6hj9mXyBlFHUaTHFA6Usz6YZi0bGs%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%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=qSasD0ckW6c6zl6hj9mXyBlFHUaTHFA6Usz6YZi0bGs%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%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=yfr5w1B3EklIrmSVAoPV5T4ten96Qe%2F30TDHSHwS46w%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%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=d73eQkK3bbLvNUeINo%2BIJrHjgy9IT7qrANobYwGnKS0%3D&reserved=0
> > > <
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=d73eQkK3bbLvNUeINo%2BIJrHjgy9IT7qrANobYwGnKS0%3D&reserved=0
> > > ><
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=d73eQkK3bbLvNUeINo%2BIJrHjgy9IT7qrANobYwGnKS0%3D&reserved=0
> > > <
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=d73eQkK3bbLvNUeINo%2BIJrHjgy9IT7qrANobYwGnKS0%3D&reserved=0
> > > >>
> > >
> > >
> >
> > --
> >
> > <
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=nJPHUMexoC7saf7a6MrfOQWYf%2FYdpFJTTes%2Bmgjc%2BNE%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%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520686567&sdata=nJPHUMexoC7saf7a6MrfOQWYf%2FYdpFJTTes%2Bmgjc%2BNE%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%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520696571&sdata=%2BS%2B5eRSKU%2B3URIdfVfza0%2Fph3VjUjrk5hWRGTJXEhi8%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
> >
> >
> >
>
> --
>
> <
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7Caharui%40adobe.com%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520696571&sdata=6PTVtYdOOp3s4eF0zwTq7uRo5xxpbvl1T3TZdUIY20g%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%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520696571&sdata=6PTVtYdOOp3s4eF0zwTq7uRo5xxpbvl1T3TZdUIY20g%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%7C6753ab6b39bc4ed6247a08d66054c398%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802314520696571&sdata=%2BS%2B5eRSKU%2B3URIdfVfza0%2Fph3VjUjrk5hWRGTJXEhi8%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
>
>
>
