advanced re-motion mixins -- mixin configurations

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:

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:

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.