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:
Unable to render embedded object: File (master-config.png) not found.
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:
Unable to render embedded object: File (each-thread-mixin-config.png) not found.
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.