Page Comparison

{remotion-mixins-disclaimer} 


The previous pages of this tutorial cover how most programmers use re-motion mixins most of the time. This page gives you some background information and shows how to use re-motion mixins _dynamically_, i.e. how to mix classes at run-time in an ad-hoc fashion. 

Attributes like {{Uses}} and {{Extends}} are compiled together with their respective target- and mixin classes and show up in the executable containing
the resulting .NET IL code. When the re-motion mixins framework starts up, usually upon first use of {{ObjectFactory}}, it inspects the executable of your application (= your code, can also be your library) and builds a _mixin configuration_ based on what it finds in your executable. This configuration is a representation of which class mixes with whom and becomes the _master configuration_ during the initialization of re-motion mixins in your application (or library). From this point on, each thread in your executable will get a reference to that master configuration, so that a call to the object factory can instantiate mixed classes based on your programming. Here is an illustration:

!master-config.png!

1.) As {{ParrotDemo.exe}} starts running, it initializes re-motion mixins as soon as the {{ObjectFactory}} is used for the first time. The initialization code inspects {{ParrotDemo.exe}} and builds a representation of all the target classes, mixin classes and how they are mixed. This representation becomes the default _master configuration_. 

2.) Each thread that starts up gets his own configuration pointer set to the master configuration per default. This configuration is the thread's _active configuration_. Using {{ObjectFactory}}, each thread can now instantiate mixed classes to its heart's content.

This _default_ master configuration is a special case of a mixin configuration. Like all mixin configurations, it is an instance of class {{MixinConfiguration}}. However, the setup illustrated above is just the _default_. At run-time you can exert much more control over mixin configurations. 

You can instantiate and construct your own mixin configurations at run-time, even give each thread its own mixin configuration or swap in and out particular mixin configurations temporarily in a thread. Here is an illustration for an alternative custom-setup where each thread points to its own mixin configuration:

!each-thread-mixin-config.png!

{{MixinConfiguration}} instances can't be modified after being built. In order to create another mixin configuration, you build upon an existing 
configuration, add configuration items to it (or remove configuration items) and build another configuration from that. If you want to go all the way, build a completely new configuration and add configuration items to that.