Mixin scopes are useful for mixing at run-time and limiting the "reach of action" for certain mixins. If nothing else, this is eminently useful for testing. This page explains how to construct and use mixin scopes. The Hotel mixin sample's
Hotel.Tests project makes good use of transaction scopes for testing.
In the previous example, we have made an entirely home-grown configuration the active configuration for the entire thread. For the following example, we will introduce three modifications to that idea.
- We will derive our custom configuration from the existing default master configuration (which in turn is a reflection of all the
Usesattributes in the application).
- Instead of adding to that configuration, we will remove from it with
- We will make the custom configuration active within a limited scope, i.e. temporarily.
Since the simplistic dessert wax sample does not lend itself very well to our sophisticated endeavor, we will resort to the slightly more advanced parrot on a unicycle here.
The following sample is based on the class hierarchy of parrots from the page
Parrot being the base class for
The entire hierarchy is extended by the
CircusMixin which gives the entire hierarchy the ability to ride a unicycle. This configuration is read in and made the master configuration, which in turn is the active configuration for the given task.
Since we can't modify an existing configuration, we have to build a new one based upon the active configuration and make the active configuration for our thread.
As explained on page re-motion mixins basics -- what about sub-classes of the target class? the entire class hierarchy is extended by a mixin if that mixin is applied to the base class. In our example, we will exempt the
Macaw class from being mixed. The new methods in the following snippet are
MixinConfiguration.BuildFromActive ()– clones the active configuration
SupressMixin<> ()– removes the specified mixin from the given class
At this point we have a new mixin configuration in the
myMixinConfiguration variable. It is exactly like the default master configuration that has been assembled from inspection of the executable. In the default master configuration, the
CircusMixin is applied to
Macaw. In our improved clone, the
CircusMixin is only applied to
GreyParrot. Note that we haven't made the configuration active yet. Remember that we want to do it temporarily, not for the entire life-time of the thread. For this, we have to create a mixin configuration scope from
myMixinConfiguration. You do this with the method
using spans the scope for which the configuration is active. As soon as execution of the code passes the closing bracket
} of the
using, the cloned configuration vanishes and the previous configuration becomes active again. (People who know the PhoneBook tutorial will recognize this mechanism: this is how re-stores transaction scopes work.)
You can even nest such scopes to arbitrary depth:
The following code sample utilizes
using for our special configuration that has mixing for
If you need the new configuration only once, you can directly call
EnterScope on the builder without using
BuildConfiguration is useful when you need to store the configuration in a variable in order to use it more than once.
You find the complete sample code for this exercise in subversion
A more elaborate, and common, application of mixin scopes can be found in the unit-tests of the Hotel mixin sample, discussed there.