Fabian's Mix

Mixins, .NET, and more

Archive for the ‘mixins’ Category

re-mix: The Mixin-Based Composition Pattern

without comments

At rubicon, we implement various applications based on our business case processing product called ActaNova. ActaNova is a piece of software that implements electronic records management (and more) in a standard way. Those specific applications we implement on top of it extend the standard domain model, UI, database schema, and so on with application-specific behavior and structure.

This has quite a few interesting effects on the technical implementation. For example, we need a way to allow the UI to be extended (and modified) by modules added to the application. In this post, however, I’d like to concentrate on the idea of building a domain model that is extensible by modules within the application. And I’ll use a pattern based on mixins (as provided by re-mix), which we call the Mixin-Based Composition Pattern.

The pattern allows us to do two things:

  • Define a domain class as an aggregation of functionality defined by different modules within the application, and
  • extend the domain class from modules added to the application.

Consider a simple Person class, as it could be defined by an electronic records management software. Note that I’m not talking about the actual current or future implementation of ActaNova here, I’m just inventing an example that lets me illustrate the pattern. Let’s say a Person has the following features, implemented by various modules within the records management product:

  • It is an entity in the domain model, so it has got an ID.
  • It also has a first name, last name, middle names, and date of birth as standard properties.
  • It is versioned, which means that changes made to its data don’t simply overwrite any previous values, but put them into a history object. Versioning is implemented in a generic fashion by the Versioning module.
  • It is also tenant-bound, which means that it belongs to a specific tenant within the application (and only in the context of that tenant can it be loaded, edited, and changed. Tenant handling is implemented in a generic fashion by the Tenant module.

A specific employee records management application is built around the standard records management software. It creates an Employee domain class that derives from Person. Different modules extend the standard Person class as follows:

  • The Employee domain class has a job description property in addition to the inherited Person properties.
  • The Human Resources module adds the current salary of the employee.
  • The Organizational Structure module adds the current manager of the employee.

Here’s a picture of how you could model this domain by using mixins:

ComposedObjects

As you can see, the Person class aggregates the versioning and tenant binding functionality defined by the respective modules by using generic mixins exposed from those modules. The Employee class derives from the Person class and is extended by mixins from within the Human Resources and the Organizational Structure modules. This is a combination of simulating multiple inheritance via mixins (reusing code by including mixins into your classes) and use-case slicing, also implemented via mixins (implementing different slices of your code separately, use case by use case). (And in case you’re wondering, the OnLoaded and OnCommitting methods in the picture are considered to be infrastructure methods exposed by all domain objects.)

Using re-mix, this all works really nicely, with one caveat: when you have an instance of Person or Employee and want to access those properties added by mixins, you need to cast the instance to IVersionedObject, IPaidEntity, and so on. Which is not very nice, which is why the Mixin-Based Composition Pattern adds the following conventions:

  • A composed object (such as Person) must provide a This property of a type TComposedInterface. The TComposedInterface type must be an interface derived from all the interfaces introduced by used mixins. (In the example, that would be an ICompletePerson interface, inheriting from IVersionedObject and ITenantBoundObject.) The TComposedInterface can also provide properties defined by the core object itself. (I.e., ICompletePerson can also provide the ID, FirstName, LastName, MiddleNames, and DateOfBirth properties.)
  • Mixins that extend a specific class must also provide a conversion method As…() as an extension method for instances of that target class. The conversion method returns the instance cast to the interface introduced by the mixin.

These conventions allow client code to access all members added by used mixins via the This property and all members added by extending mixins via the As…() extension methods. This makes it very convenient to work with a domain implemented via mixins. Here’s an example of how the Employee class shown above would be used:

var employee = ObjectFactory.Create<Employee>();

 

Console.WriteLine (employee.ID);

Console.WriteLine (employee.FirstName);

 

// Properties added by mixins included by the Person/Employee classes

Console.WriteLine (employee.This.TenantID);

Console.WriteLine (employee.This.VersionID);

 

// Properties added by mixins extending the Person/Employee classes

Console.WriteLine (employee.AsOrganizedEntity().Manager);

Console.WriteLine (employee.AsPaidEntity().Salary);

re-mix has a ComposedObject<TComposedInterface> base class that provides the This property, so implementing the Person class could be as simple as this:

public interface ICompletePerson : IVersionedObject<Person>, ITenantBoundObject {}

 

[Uses (typeof (VersioningMixin<Person>))]

[Uses (typeof (TenantBindingMixin))]

public class Person : ComposedObject<ICompletePerson>

{

  public Person (int id)

  {

    ID = id;

    MiddleNames = new List<string>();

  }

 

  public int ID { get; private set; }

  public string FirstName { get; set; }

  public string LastName { get; set; }

  public List<string> MiddleNames { get; private set; }

  public DateTime DateOfBirth { get; set; }

 

  // etc.

}

(I’ve given the IVersionedObject interface a generic parameter, just to show that this is possible.)

But even if you can’t (or don’t want to) use the ComposedObject base class, implementing the This property by hand is very simple:

public class

    : IHasCompleteInterface<TComposedInterface>

{

  // etc.

 

  public TComposedInterface This

  {

    get { return (TComposedInterface) this; }

  }

}

The IHasCompleteInterface marker interface just causes re-mix to include the given interface on the domain object type (without the domain programmer having to implement its methods).

Here’s an example of one of those As…() extension methods, as it would come with the HumanResources module:

public static class EmployeeExtensions

{

  public static IPaidEntity AsPaidEntity (this Employee employee)

  {

    return (IPaidEntity) employee;

  }

}

No magic there, either, just some syntactic sugar to avoid users having to make those casts.

To summarize, by implementing the Mixin-Based Composition Pattern, you can:

  • build your domain classes by means of aggregating functionality from different modules in the application by using mixins exposed from those modules,
  • access members added by those mixins nicely via the This property,
  • extend your domain model from external modules by having mixins in there that extend the domain classes, and
  • access members added by those mixins nicely via the extension methods provided with the mixins.

This makes for very extensible, yet nicely factorized and simple to use domain models.

(One word about persistence and O/R mapping: Our own O/R mapper “re-store” recognizes mixed entities, and it persists properties added by the mixins into the database. It’s of course possible to implement the same behavior for other O/R mappers and persistence frameworks as well if they provide the necessary extensibility points. Whether to put the mixin data into the same database tables as the core domain data is another topic and depends on the specific situation.)

Written by Fabian

March 16th, 2012 at 2:05 pm

Posted in mixins

re-mix: Encapsulate and share ASP.NET MVC controller actions

with 2 comments

Jan Jonas has written a blog post about how to encapsulate commonly used controller actions using mixins with ASP.NET MVC 3. I think that it’s a really cool idea to use re-mix for this, however Jan is facing a few stumbling blocks that I want to comment upon. (Actually, I wanted to post this as a comment to his blog post, but for some reason, the comment form isn’t working.)

I understand Jan is saying that ASP.NET MVC doesn’t find the action methods added by mixins because the proxies generated by re-mix don’t inherit from ControllerBase. Therefore he needs to implement a custom ControllerActionInvoker to get ASP.NET MVC to invoke action methods introduced by mixins.

Actually, the proxies re-mix generates do inherit from the mixed classes; in Jan’s example, those are Controller1Controller and Controller2Controller, i.e., the proxies do inherit (indirectly) from ControllerBase. Then why isn’t ASP.NEW MVC finding those controller actions by default?

Maybe the problem is that the proxies implement the mixin interfaces (in the example, IEchoControllerMixin) explicitly, and ASP.NET MVC probably doesn’t search for explicit interface implementations. However, one can tell re-mix to implement interface members publicly, either by putting the MemberVisibilityAttribute on the methods in the mixin, or by specifying IntroducedMemberVisibility = MemberVisibility.Public when applying the UsesAttribute. (You can also derive a custom attribute from UsesAttribute that sets IntroducedMemberVisibility to MemberVisibility.Public by default, since you’ll always want to do that for controller mixins.)

If, for some reason, that still doesn’t work, one could put the CreateActionInvoker override into the target class (Controller1Controller) rather than the mixin, or into a different mixin (e.g., a ControllerMixinSupportMixin). That would enable one to use multiple controller mixins without generating conflicts on the CreateActionInvoker method.

A second problem Jan is facing is that the controller mixins can’t access the protected members declared by the controller and its base classes. However, re-mix allows this: to give mixins access to protected members of the target class, one can specify a custom interface as the TTarget parameter to the Mixin<TTarget> base class. Just define a public interface redeclaring all the controller methods the mixins should be able to access and specify that for the TTarget type parameter. The target class doesn’t actually have to implement that interface, it just needs to provide all the members, with either public or protected visibility.

I’ve adapted Jan’s example accordingly:

public interface IMixedController
{
  ViewResult View();
  ViewResult View (string viewName);
  ...
}
public class EchoControllerMixin : Mixin<IMixedController>, IEchoControllerMixin
{
  public ActionResult Echo(string id)
  {
    var result = new ContentResult();
    var controllerName =
        Target.ControllerContext.RouteData.Values["controller"].ToString();
    result.Content = string.Format(
        "re-mix added Echo action to controller '{0}'<hr/>You said: {1}", 
        controllerName,
        !string.IsNullOrEmpty(id) ? id : "<i>nothing</i>");
    return result;
  }
}
public class UsesControllerMixinAttribute : UsesAttribute
{
  public UsesControllerMixinAttribute (Type mixinType)
    : base (mixinType)
  {
    IntroducedMemberVisibility = MemberVisibility.Public;
  }
}
[UsesControllerMixin(typeof(EchoControllerMixin))]
public class Controller1Controller : Controller
{
}

 

Feel free to ask at the discussion list (http://groups.google.com/group/re-motion-users) if you face any other issues with re-mix.

Update (2012-01-11): Fixed base attribute ctor call in code.

Update (2012-01-16): As mentioned in the comments, Jan Jonas has published a blog post discussing my suggestions.

Written by Fabian

January 10th, 2012 at 10:09 am

Posted in mixins

re-mix: Now on CodePlex

with 2 comments

Via the re-motion Team Blog: http://remix.codeplex.com/.

Check the team blog for details.

Written by Fabian

April 29th, 2011 at 1:35 pm

Posted in mixins

Mixins – Now with better memory performance

without comments

During the last two weeks I’ve implemented an improvement requested by another team at rubicon: to make re-motion mixins hold on to fewer objects.

You see, when a mixed type is instantiated for the first time, re-motion’s mixin engine generates code to represent the combination of the target type with its mixins. Before that code generation takes place, an object model of the mixed type is created, called the target class definition. It is a very verbose, interlinked collection of all the metadata that’s required to generate mixed types. The reason for its existence is that it makes code generation quite self-contained, everything more modular, etc. So far, so good.

Target class definitions are used to generate mixed types

Not so good was an idea I had immediately after conceiving the target class definition stuff. See, you have all that information that is used to generate code for mixed types. And then, you have a feature request for something called mixin reflection. This means asking questions such as, “Given a mixed type’s member, find out whether it was introduced by a mixin or comes from the target class.” Or, “Given a mixed type, tell me what mixins are applied to it.” This is exactly the kind of information held by the target class definition and its fellow objects! So what could be better than simply caching the definition model, keeping it around in the background just in case somebody asks questions such as the ones above?

Using the TargetClassDefinition to perform mixin reflection

Great idea, simple implementation, I thought: here came the TargetClasDefinitionCache. Feed it a ClassContext (which represents a combination of target type and mixin types), and it will give you all the information you need.

Or will it? Actually, it will give you all the information the code generator needs. And chances are very good that you don’t need all that information. Unless you are a code generator, of course. Chances are, in fact, extremely high that TargetClassDefinitionCache will keep an object graph with lots of definition object instances, dictionaries, lists, and so on alive – that no one will ever use!

Okay, that was a little too dramatic. After all, it was the simplest way (that could possibly work) of implementing the features of mixin reflection. And, it was not likely to bite you – I mean, how many classes would you mix in your application? 10? 50? Okay, you’ll have hundreds of dictionaries; so what?

It turned out that actually mixins were used in very big applications with many, many mixed classes. And so, the target class definition cache kept alive a lot of objects. That didn’t necessarily generate a performance problem, but it effectively made memory profiling near to impossible. Many existing profiling tools just give up if your application holds static references to hundreds of thousands of objects right after startup.

Next idea: don’t let the cache grow indefinitely, right? After all, it’s a cache, just devise some intelligent strategy of emptying it!

Well… You know. I made a mistake. It wasn’t really meant to be a cache. It was more like a data store. I just assumed (and at that time, it was true) that nobody would be hurt by my keeping all the target class definitions around. Therefore, the definitions were used as keys all over the place (reference equality!), and every generated type had a back-reference to its TargetClassDefinition object. (You could access it from a mixed instance via IMixinTarget.Configuration, btw.) So even if I pruned the TargetClassDefinitionCache, every loaded mixed type would still hold on to its object model. Tightly.

So, to make a long story short, both TargetClassDefinitionCache and the back-references are now history, all hail to TargetClassDefinitionFactory. With it, the target class definition is now generated solely for code generation, then discarded (= made collectable by the GC). In case you’re using the TypeMixer – pregenerating code and loading the generated code into memory using ConcreteTypeBuilder.LoadAssemblyIntoCache – no target class definitions should be generated at all.

And if you fear that now mixin reflection might be much slower than before – fear not: I was able to rewrite much of it using ClassContexts, which are much more light-weight (and have value semantics when compared via Equals). For all other mixin reflection tasks, the generated type and attributes attached to it are now used. Which – performance-wise – means a single call to GetCustomAttributes in most cases. (Of course, the first time a reflection call is made on a mixed type, the type is generated unless it’s already in the cache. But it usually is.)

So, this is the final picture:

Mixin reflection now works on the mixed type instead of the TargetClassDefinition

Makes a lot more sense, I think.

Written by Fabian

August 21st, 2009 at 1:20 pm

Posted in mixins

Why is re-motion so large?

without comments

Some time ago, Lee Henson, the guy who made the Castle Windsor facility for re-motion, sent me a comment about re-motion’s SVN repository. He said it was too large and a bit disorganized, at least from an outsider’s perspective. He asked whether we could start a new repository from scratch now that re-motion’s mixin implementation was open-source. That repository would only contain the relevant code and projects for re-motion mixins, thus making it easier for outsiders to come and contribute.

That surprised me. Of course it’s not a good thing at all that re-motion’s repository appears to be too large and a bit disorganized from the outside. After all, we want to attract other people, not put them off.

So, what’s the problem with our repository? When you check out the source code from SVN and open the Remotion.sln file, it looks something like this:

Remotion Solution

If you only wanted to take a look at re-motion’s mixin engine, I understand you might end up confused.

That solution is so large because it contains the whole re-motion framework. re-motion is made of many components:

Together, these components make for a lot of projects. And we can’t really reduce the number of those – re-motion just is a big framework.

Now, how can we make the experience of checking out the code of re-motion mixins more user-friendly? I have a plan, but in the meantime, please just concentrate on the Core.Core project – it contains the mixin engine in the Mixins namespace.

Written by Fabian

April 30th, 2009 at 1:10 pm

Posted in mixins

May the Params be With you

with 2 comments

This is the fifth in a series posts. The previous items are:

Last time, I announced that I’d probably write about mixins and inheritance next. That’s still on my list, but today, I would like to talk about two lines of code I’ve posted in the past and never really explained. Here they are:

ObjectFactory.Create<MyTargetClass> ().With (x, y, z);

ObjectFactory.Create<File> (ParamList.Empty);

The first line is from the post “What can we do for you? (Features of re-motion mixins)”, and in that post, I wrote:

The With is a wart, unfortunately. Short story: x, y, and z are the constructor parameters for the mixed object, and the With method takes care of their types being respected. (If you are thinking, “Why aren’t they just using a params object[]?” – because that wouldn’t respect the parameters’ types. I’ll explain another time.)

With will soon be replaced by a ParameterList object or similar, so that it will read somewhat like this:

MyTargetClass myMixedObject =
 
ObjectFactory.Create<MyTargetClass> (ParameterList.Create(x, y, z));

So, With was a wart, and it has been replaced. Not by a ParameterList object, but by a ParamList object. But why had it been there in the first place?

To answer this, let’s take a look at the interestingly amusing topic of dynamically instantiating classes. With parameters.

Suppose you are implementing a framework, for example one providing mixin support for statically typed .NET languages. To do so, you will probably need to provide a generic factory, ie. a class that allows dynamic instantiation of arbitrary objects. Let’s call it TheObjectFactory:

public class TheObjectFactory

{

  public static T Create<T> (…)

  {

    …

  }

}

How do you implement that Create factory method so that you can pass it an arbitrary number of arguments?

The standard way to do this in .NET is a params array. It looks as follows:

public static class TheObjectFactory

{

  public static T Create<T> (params object[] args)

  {

    …

  }

}

With a params array, the C# compiler allows the Create method to be called with any number of arguments. It will wrap them up into an array and pass that array to the method at runtime. This is the approach used by factory methods in the .NET framework library, such as Activator.CreateInstance, so it can’t be wrong, can it?

Well, most of the time it works. Unless you are in one of the following situations:

  • You want to pass a single argument to the factory method and the argument is an array.
    In this case, the C# compiler thinks the array you’re passing is the params array, and it will thus not wrap it up.
    At runtime, the factory method will then look for a constructor with a signature corresponding to the array’s elements, which will either fail or find the wrong constructor.
    The workaround is to manually wrap up the array into another array and to pass that wrapper as the params array.
  • You want to pass a single argument to the factory method and the argument is null.
    Again, the C# compiler will think the null you’re passing is the params array, and again, it will not wrap it up.
    At runtime, the factory method will either throw an exception or think you’re looking for the default constructor (Activator.CreateInstance does that).
    The workaround is again to manually wrap it up.
  • You want to pass a null argument to the factory method, and there are two or more constructors accepting reference types.
    Even when your null value is wrapped up correctly, overload resolution at runtime will fail if more than one constructor accepting reference types exists.
    Of course, this must fail, after all, you cannot infer which of the constructors to call.
    However, the workaround is really awkward: you need to pass an additional Type array, which denotes the signature of the constructor to be called.

These situations tend to surface quite often, they surface only at runtime, and sometimes you might not even notice you’re calling the wrong constructor! Also, the workarounds aren’t really beautiful.

Therefore, we considered other possibilities for passing arbitrary arguments to a factory method. And we (well, Stefan, actually) had an idea: we could exploit C# generics to have the C# compiler hand over the type information together with the argument’s values. This was first implemented in a fluent interface way (With), which worked nicely but was a little unintuitive, so it got rewritten as a generic parameter object (ParamList).

ParamList is implemented as follows:

public abstract class ParamList

{

  public static ParamList Empty = new ParamListImplementation ();

 

  public static ParamList Create () { return Empty; }

 

  public static ParamList Create<A1> (A1 a1)

  {

    return new ParamListImplementation<A1> (a1);

  }

 

  public static ParamList Create<A1, A2> (A1 a1, A2 a2)

  {

    return new ParamListImplementation<A1, A2> (a1, a2);

  }

 

  public static ParamList Create<A1, A2, A3> (A1 a1, A2 a2, A3 a3)

  {

    return new ParamListImplementation<A1, A2, A3> (a1, a2, a3);

  }

 

  // More Create overloads …

  public abstract object InvokeConstructor (

      IConstructorLookupInfo constructorLookupInfo);

}

The ParamList.Create methods have overloads taking up to 20 generic arguments. When one of them is called, the C# compiler will automatically infer the generic argument types from the actual parameters specified at the call site, and the method will instantiate a specific ParamListImplementation object that not only knows the parameter values but also the parameter types inferred by the compiler.

There are variants of the ParamListImplementation classes for up to 20 generic arguments as well, and each of those implements the InvokeConstructor method. Here is one of them (from the overload with one generic argument A1):

public override object InvokeConstructor (

    IConstructorLookupInfo constructorLookupInfo)

{

  var funcDelegate =

      constructorLookupInfo.GetDelegate (typeof (Func<A1, object>));

  return funcDelegate (_a1);

}

InvokeConstructor gets passed a IConstructorLookupInfo object, which has the ability to lookup constructors with a specific signature and return a delegate calling that constructor. This is used with the actual parameter types inferred when calling the Create method, and the delegate is called with the argument passed to the method.

With ParamList, the factory can be implemented as follows:

public static class TheObjectFactory

{

  public static T Create<T> (ParamList ctorArgs)

  {

    var info = new ConstructorLookupInfo (typeof (T));

    return (T) ctorArgs.InvokeConstructor (info);

  }

}

Now, why does this help us?

First, the common usage scenarios of the factory still work. You can create a ParamList with an arbitrary number of arguments (see below about the limit of twenty), and type inference will ensure that the ParamList passes the right argument types on to the ConstructorlookupInfo.

Second, the cases I mentioned above, now either work, yield a compiler error, or at least offer a decent solution:

  • You want to pass a single argument to the factory method and the argument is an array.
    In this case, the C# compiler will infer that you are passing an array, and the ConstructorLookupInfo will look for a constructor taking an array. Works.
  • You want to pass a single argument to the factory method and the argument is null
    Here, the C# compiler will not be able to infer the type (since null does not have any ordinary type). It will will yield a compiler error, but you can cast the null value to a specific type.
  • You want to pass a null argument to the factory method, and there are two or more constructors accepting reference types.
    This must fail at runtime, but to make the call non-ambiguous, you can cast the value to one of the specific types taken by the constructors.

Since it eliminates two possibilities for silent failure and adds a decent way of removing the ambiguity for the third, we decided to go this way with re-motion’s ObjectFactory class.

But what about the limit of 20 arguments? If you really need to call a constructor with more than 20 arguments (what?!), you can use the ParamList.CreateDynamic method, which falls back to the array approach. But this really shouldn’t be needed on a regular basis.

So, to wrap this up: re-motion’s ObjectFactory has to be able to take an arbitrary number of constructor arguments. We didn’t want to go the params array route because that has a few important shortcomings. Therefore, we built a parameter object ParamList, which uses C#’s generic type inferencing features to not only collect the constructor arguments’ values but also its types. What we gained is cleaner overload resolution, fewer gotchas, and better type safety.

Written by Fabian

March 2nd, 2009 at 2:48 pm

Declare mixins, not war!

with 3 comments

This is the fourth in a series posts. The previous items are:

Last time, I briefly mentioned configuration as a feature of the re-motion mixin implementation. In the context of mixins, the term “configuration” refers to what mixins are mixed into what target classes, and with what properties the mixing is performed.

To be honest, the notion of configuration is more a prerequisite than a feature – without the ability of assigning mixins to target classes, a mixin implementation would be rather stupid. Or… not a mixin implementation at all, actually. What is a feature, however, is how many ways of configuration we allow.

I quickly repeat them from my last post:

  • A class can declaratively choose to be extended by one or more mixins.
  • A mixin can declaratively choose to extend one or more classes.
  • An application can declaratively choose to combine mixins and classes.
  • A programmer can – at run-time – choose to combine mixins and classes.
  • (Any person can – at deployment time – choose to combine mixins and classes.)
    –> planned, but not implemented yet

Today, I’ll write about the first three topics – the declarative configuration possibilities.

A class can choose its mixins

When you write a new class, you can explicitly pull in a number of mixins into that class. This feature is similar to inheritance (where you explicitly derive from a base class), and it enables scenario (1) from my post on usage scenarios:  having a class reuse an implementation supplied by a mixin.

Let’s look at an example:

[Uses (typeof (MyMixin))]
public class MyClass
{
}

That’s quite self-explaining, I think – MyClass has chosen to use (ie. include) the reusable code provided by MyMixin.

Now, what would you use that for, and what additional properties can you specify?

You would choose this form of configuration when you have a mixin providing a feature that you want your class to expose. The mixin’s implementation actually becomes part of the class’s implementation. Think of deriving from a base class, or of aggregating and delegating to another component. For example, you could want to make your class cloneable by reusing a mixin:

[Uses (typeof (CloneabilityMixin))]
public class MyCloneableClass
{
}

And the test:

[Test]

public void MyCloneableClass_IsICloneable ()

{

  var instance =
    ObjectFactory.Create<MyCloneableClass> (ParamList.Empty);

  Assert.That (instance, Is.InstanceOfType (typeof (ICloneable)));

}

(We will look at the actual implementation of the CloneabilityMixin at a later time.)

That way, the class will always support cloning, the implementation supplied by the mixin has become a part of MyClass’s implementation.

The UsesAttribute supports the following optional parameters:

  • IntroducedMemberVisibility: As you know from my feature post, mixins can add interface implementations to the mixed object. By default, the members added by such an interface implementation are explicit implementations, ie. private. If you need those members to be made public, which might make sense in some reflection scenarios, you can do so by specifying MemberVisibility.Public to the attribute.
  • AdditionalDependencies: I will write about dependencies in another post, but for now it should be enough to say that mixins can have dependencies on other mixins, either directly or indirectly. Dependencies influence the base call order when more than one mixin overrides the same members, and they also define what a mixin can rely on when it accesses the mixed object. Explicit dependencies can be defined via this parameter by passing an array of mixin types to the attribute.
  • SuppressedMixins: By default, every target class inherits the mixins configured for its base classes. Sometimes, however, a class might want to replace an inherited mixin with another one – so the new mixin declaration needs to suppress a previous one. Which is what this attribute parameter is for.

Uses is nice, but you could argue that you could replace it simply by having your class hold an instance of the mixin and delegate to it, or even by deriving your class from the mixin. In reality, that “simply” will usually not be so simple at all, because delegation quickly becomes cumbersome and lengthy, and base classes are scarce (only one per class) in the .NET world. Still, let’s look at something you can’t do that easily with manual delegation or inheritance.

A mixin can choose its target classes

Consider scenario (2) from my usage scenario post: you have a finished class model, but need to adapt it. How do you do that?

That’s easy – just create a mixin specifically for those target classes you need to adapt:

[Extends (typeof (MyClass))]

public class MyMixin

{

}

Now, while this might seem to be only an inversion of the example given above, semantically it’s much more: It allows a mixin to extend a class from the outside. So, if we follow the base class analogy, this would be like specifying the base of a class from the outside. Try this in C# :)

To give a more realistic example, consider a scenario where you have a pre-implemented file management domain, and you have a client requirement to number files in a specific format. While you could simply derive from the pre-implemented File class to add that information (and hope your domain uses inversion of control to instantiate its File objects…), consider that your domain might already contain CarFile, PersonFile, and other subclasses of File. That would quickly result in a subclassing orgy, and all of the subclasses would hold the same delegation code!

So, how to do this, then? Remember, classes automatically inherit mixins from their base classes, so if we implement mixin for this, it should be much more efficient. And it is:

[Extends (typeof (File))]

public class NumberedFileMixin : INumberedFile

{

  private readonly string _id = Guid.NewGuid ().ToString();

 

  public string GetFileNumber ()

  {

    return _id;

  }

}

And the test for this:

[Test]

public void File_IsNumbered ()

{

  var numberedFile = (INumberedFile)
    ObjectFactory.Create<File> (ParamList.Empty);

  var numberedCarFile = (INumberedFile)
    ObjectFactory.Create<CarFile> (ParamList.Empty);

  var numberedPersonFile = (INumberedFile)

    ObjectFactory.Create<PersonFile> (ParamList.Empty);

 

  Assert.That (numberedFile.GetFileNumber (),

    Text.Matches (“……..-….-….-….-…………”));

  Assert.That (numberedCarFile.GetFileNumber (),

    Text.Matches (“……..-….-….-….-…………”));

  Assert.That (numberedPersonFile.GetFileNumber (),

    Text.Matches (“……..-….-….-….-…………”));

}

(Note that I needed to cast to INumberedFile because the C# compiler can’t know that File now implements INumberedFile via a mixin. There are ways to avoid the cast, but that will go into a separate blog post…)

The ExtendsAttribute supports the same optional arguments as the UsesAttribute does (IntroducedMemberVisibility, AdditionalDependencies, and SuppressedMixins), plus one:

  • MixinTypeArguments: Consider the case where you have a generic mixin (if you can’t imagine this, take a look at Stefan’s blog post about mixins in domain design). re-motion’s mixin implementation has an algorithm that tries to supply the type arguments automatically when the mixin is instantiated, but sometimes, the algorithm won’t be able to figure out what you want. In these cases, you’ll need to specify the type arguments by hand using this attribute. (Prize question: Why doesn’t the UsesAttribute need this parameter?)

So, you use the ExtendsAttribute when you write a mixin for specific target classes, and you use the UsesAttribute when you write a class using a specific mixin. Can there be anything else?

Well, what if you want both classes and mixins to be fully oblivious of each other?

An application can combine mixins and classes

Say, for example, you reference a DLL with a finished class model, and you also have a catalog of adaptation mixins for different client scenarios. Now, in your application, you just need to combine the relevant mixins with the respective domain classes. re-motion also supports this:

[assembly: Mix (typeof (MyClass), typeof (MyMixin))]

In this case, the programmer has chosen (via an assembly-level attribute) that instances of MyClass should be mixed with MyMixin in the context of the application. Let’s apply the same to the file numbering sample from above:

[assembly: Mix (typeof (File), typeof (IdentifiedObjectMixin))]

And the test:

[Test]

public void File_HasID ()

{

  var numberedFile = (IIdentifiedObject)

    ObjectFactory.Create<File> (ParamList.Empty);

  var numberedCarFile = (IIdentifiedObject)

    ObjectFactory.Create<CarFile> (ParamList.Empty);

  var numberedPersonFile = (IIdentifiedObject)

    ObjectFactory.Create<PersonFile> (ParamList.Empty);

 

  Assert.That (numberedFile.GetObjectID(),

    Text.Matches (“……..-….-….-….-…………”));

  Assert.That (numberedCarFile.GetObjectID(),

    Text.Matches (“……..-….-….-….-…………”));

  Assert.That (numberedPersonFile.GetObjectID(),

    Text.Matches (“……..-….-….-….-…………”));

}

Note that I’ve renamed the mixin and the interface to denote a more general mixin implementation. This is exactly the point: the MixAttribute allows you to combine completely general (or “oblivious”) classes and mixins.

The attribute accepts the same properties as the UsesAttribute (IntroducedMemberVisibility, AdditionalDependencies, and SuppressedMixins), plus one:

  • MixinKind: Now, what’s that? This parameter takes an Enum value that allows you to choose: do you want to regard the mixin to be extending the target class, or the class to be using the mixin? That’s not really important from the point of view of the mixin engine, but there might be user code that needs to differentiate between these two scenarios. And for such user code, you can specify the relationship. (The default is MixinKind.Extending, by the way.)

So, to wrap it up, re-motion offers three forms of attribute-based declarative mixin configuration:

  • The UsesAttribute, by which a class can include mixins, which is similar to inheritance,
  • the ExtendsAttribute, by which a mixin can extend a class, which is good to adapt classes from the outside, and
  • the MixAttribute, by which an application programmer can combine any class with any mixin.

Use them wisely, and you shall prevail.

Next time: Probably something short about mixins and inheritance.

Edit: You can find the code for this blog entry here:
<https://svn.re-motion.org/svn/Remotion/trunk/Remotion/Core/Mixins.Samples/Tutorial/T01_Configuration/>.
The tests are here:
<https://svn.re-motion.org/svn/Remotion/trunk/Remotion/Core/Mixins.Samples/UnitTests/Tutorial/T01_Configuration/>.

Written by Fabian

February 2nd, 2009 at 10:39 am

Posted in mixins

We have a Facility!

with 2 comments

Lee Henson has implemented a Castle Windsor facility for re-motion’s ObjectFactory class. With it, it is possible to have the container resolve components that are mixed by re-motion. Lee’s original intention was to have a mixed MonoRail controller, which should now be perfectly possible.

Quoting from Lee’s announcement on the Castle developers list:

Sample usage is the specs in the project, but sample (notepad) code
would be:

<wherever you are creating your container>

var remotionFacility = new RemotionFacility
(assemblyContainingMyMixins);
container.AddFacility(“remotion.facility”, remotionFacility);

<register components>

<later on>

var component = container.Resolve<ComponentWithAvailableMixins>();
((MyMixin) component).SomeMethod();

Here’s the link: http://github.com/leemhenson/re-motion/tree/c98d2439d8e78a31cc866ecc47a772b5a74ec34f/RemotionFacility.

UPDATE: We now have a Remotion-Contrib repository, find the facility here: https://svn.re-motion.org/svn/Remotion-Contrib/WindsorFacility/trunk/.

Thanks a lot for making this work, man!

How it works

Lee and I mailed around a little to see how to do this, and while Lee did all the implementation work, it’s quite easy to explain what it does. The RemotionFacility is a simple Windsor facility that hooks up a special RemotionActivator class for components that have mixins configured. That activator uses re-motion’s ObjectFactory to instantiate the component (after all of its constructor dependencies have been resolved) – and voilà, there is your mixed component.

What can go wrong

The RemotionFacility has constructors allowing you to use an auto-generated configuration, specify the assemblies to scan, or specify a dedicated MixinConfiguration instance. However, even when you specify the configuration by hand, re-motion will still want to do an assembly scan of those assemblies in your bin folder at runtime. This is the default policy and cannot be easily disabled in the current re-motion trunk revisions, so you might get exceptions when you have assemblies with dangling references in your project’s bin folder. Such an exception is nearly always a deployment bug, so you should really clean up your folder, but if you can’t (or don’t want to), the only way around it currently is to set a custom ITypeDiscoveryService via ContextAwareTypeDiscoveryUtility.SetDefaultInstance(…) before doing anything mixin-related. (Or, better, before doing anything re-motion-related, since a lot in re-motion is mixin-related.)

(This will be fixed to make it easier in the future.)

EDIT (2009-02-10): Updated link to facility.
EDIT (2009-03-23, 2011-04-22): Updated link to facility. Again.

Written by Fabian

January 21st, 2009 at 1:26 pm

.NET versions, and: What is a GDR?

without comments

Microsoft’s naming strategy has always been a little controversial. Mostly, because there seem to be several different strategies. It is somewhat funny that the marketing division(s) can’t seem to make up their mind about how to call their products. Take a look at the following Microsoft product names (those are only excerpts):

  • Windows versions: 3.1, 95, 98, ME
  • Windows NT versions: NT 4, 2000, XP, Vista (and now, finally, 7)
  • Office: 95, 97, 2000, XP, 2003, and “the 2007 Microsoft Office system

And, is it really necessary that Vista ships in six editions? (According to Wikipedia, they are Windows Vista Starter, Windows Vista Home Basic, Windows Vista Home Premium, Windows Vista Business, Windows Vista Enterprise, and Windows Vista Ultimate. Not counting the “N editions”, because Microsoft isn’t really accountable for them.)

But of course, common sense is common sense whereas marketing is marketing. While I find it somewhat funny, I don’t really mind.

What I do mind, however, is Microsoft’s naming schema with the .NET platform, because that one’s really confusing. I’ll present a list of the existing .NET versions, simply so that I have a place to look it up in the future. If you get bored, please jump to GDR to the Rescue.

The First Ones

  • .NET 1.0 (including C# 1, CLR/BCL version 1.0): This was the first version of .NET, and thus, it was aptly named, I think.
  • .NET 1.1 (including C# 1, CLR/BCL version 1.1): This fixed a few bugs and APIs, and added a little bit. Was it aptly named? I think it didn’t add enough for a new major version, so probably yes.
  • .NET 2.0 (including C# 2, CLR/BCL version 2.0): This was a big change to both the platform and the programming languages. It introduced generics, nullable types, lots of new classes in the Base Class Library, and so on. It was also a side-by-side release, ie. you had the option to install both .NET 1.1 and 2.0 on the same machine. Great. Sadly, it was also the last of the sensibly named versions.

The Strange Version 3.0

  • .NET 3.0 (including .NET 2.0, WCF, WPF, WF, Windows CardSpace): This only added new libraries, it didn’t change the Base Class Library at all, and it also didn’t change the underlying platform. Any .NET application developed for 3.0 also worked on 2.0 unless it made use of one of the new libraries. Any .NET application developed for 2.0 also worked on 3.0 because 3.0 was not really a new version of .NET. It’s hard to say whether it was a side-by-side version or replaced 2.0, since it only added a few DLLs to an existing installation of .NET 2.0. The only reason, in my opinion, to call this “3.0″  was for it to sound better, and it really confused the quite many developers. But it got worse.

The 3.5 Family

  • .NET 2.0 SP1 (including C# 2, CLR/BCL version 2.0 SP1): I guess, this update fixed a few issues, but actually, it was designed to extend the CLR and BCL for the upcoming .NET 3.5, and thus it added a few members to existing classes in the Base Class Library. One that I took notice of was an additional overload in TypeBuilder.DefineProperty, which I made use of in re-motion, causing the framework to throw MissingMethodExceptions on other colleagues’ PCs. I think this version was not aptly named at all. Why make a service pack for .NET 2.0 with changes needed only by a subsequent version? But this decision was part of the .NET 3.5 misery.
  • .NET 3.0 SP1 (including .NET 2.0 SP1, WCF, WPF, WF, Windows CardSpace): This was essentially .NET 3.0 but with .NET 2.0 SP1 applied. Since 3.0 was only 2.0 with libraries, 2.0 SP1 with those libraries became 3.0 SP1. Not confused yet? It gets worse…
  • .NET 3.5 (including C# 3, .NET 3.0 SP1, LINQ): Now, this version introduced new versions of the main .NET programming languages, and it added LINQ. The CLR and BCL changes were already packaged as .NET 2.0 SP1, so 3.5 only needed to add some libraries (System.Core probably being the most important one). Of course, if you didn’t make use of the new libraries, your .NET 3.5 applications were actually .NET 2.0 SP1 or .NET 3.0 SP1 programs. In my opinion, this was a catastrophe. Why release the changes to the CLR and BCL separately as service packs for 2.0 (and thus 3.0), and then call the service packs plus libraries .NET 3.5? Why not make a new .NET 4.0 version, running side-by-side? Is the end goal total confusion? But, believe it or not, it got worse.

The 3.5 SP1 Disaster

  • .NET 2.0 SP2 (including C# 2, CLR/BCL version 2.0 SP2): For .NET 3.5 SP1 (see below), a few changes to the CLR and BCL were needed again. Since 3.5 SP1 would still not contain a new version of the CLR and BCL, these changes had to be a service pack for .NET 2.0. I’ll explain its effects below.
  • .NET 3.0 SP2 (including .NET 3.0 SP2, WCF, WPF, WF, Windows CardSpace): The libraries of .NET 3.0 plus the CLR and BCL of .NET 2.0 SP2.
  • .NET 3.5 SP1 (including C# 3, .NET 3.0 SP2, LINQ, ADO.NET Entity Framework and Data Services, as well as some prerequisites for ASP.NET MVC) : This one was the perfect disaster. One of the goals of SP1 was to offer a lot of performance improvements, fix a few bugs, and add new features. For this, it required quite a few CLR changes (which were packaged separately as .NET 2.0 SP2, since 3.5 didn’t really need a new CLR, ahem…). You know, .NET 3.5 SP1 was required by SQL Server 2008 and thus linked to SQL Server’s release date. And in my opinion, that release date pressure lead to the fact that .NET 3.5 SP1 (and .NET 2.0 SP2 and .NET 3.0 SP2) introduced a lot of bugs. Really, a lot of bugs. Bugs in serialization, in Windows Forms, reflection (see also Stefan’s and Ayende’s post on this topic), WPF, type checking, and the C# compiler. And this is only an excerpt. Bugs not only in new features, but also in APIs that had been working nicely for a long time. This was probably one of the worst service packs ever. And it leads to a nice new three-letter acronym getting known better: GDR.

GDR to the Rescue

After the .NET 3.5 SP1 problem (with numerous easily reproducible bugs popping up on Microsoft Connect and many blog posts being written), Microsoft relatively quickly started to provide hotfixes for many of the issues. KB957541 for example. But, of course, hotfixes are only meant to be installed if you’ve already hit the wall, and they are a bit of a nightmare when you’re developing software that depends on them. (“Dear customer, before using my software, please install KB957541.” Sounds easy, often isn’t.)

So, it was communicated quite early that these hotfixes would be aggregated into one package (a service pack for the service pack, so to speak), which would be available for general download (and later, it would come via Windows Update at the same time .NET 3.5 SP1 got distributed there). At Microsoft, this is called a General Distribution Release, or GDR.

Scott Hanselman:

A GDR is a Microsoft TLA (Three Letter Acronym) for an update that is for everyone.

Later than announced, the GDR is finally here. (For manual download.)

(And still, it’s somewhat broken. For example, the GDR repairs issue KB957541 - I’ve verified this -, but the knowledge base article (as of 2009-01-15) doesn’t mention it in the list of fixed issues. I’ll report that, maybe it will get fixed.)

The Essence

Now, we finally have another version of .NET that we can work with. It hasn’t got an official name yet, so I’ll just call it “.NET 3.5 SP1 + GDR”. Some parts of re-motion (mostly the web part, re-call) need to make use of additions made in .NET 3.5 SP1.

“To use re-motion 1.11.x, you need to have .NET 3.5 SP1 + GDR.”

“We already have .NET 2.0, and applications running on it. What should we do, and is it safe?”

Exercise: Answer these two questions. And: Are you sure it won’t break anything?

(How simple it would be to just say: Please install .NET 3.2 side-by-side.)

Update 2009-03-09: Fixed typo in Scott Hanselman’s name

Written by Fabian

January 15th, 2009 at 12:39 pm

What can we do for you? (Features of re-motion mixins)

without comments

This is the third post in a series of posts about re-motion mixins, and this is the one where I’m finally going to tell you about the core of the re-motion mixin library. Last time, I explained that mixins are about extensibility. They are about taking two pieces of code and integrating them so that the combination makes sense in the context of a new application. The two pieces of code are the target class and the mixin, and the combination is the mixed object.

So, the first two and most important features of re-motion mixins are the following:

  • It allows you to configure mixins for target classes.
  • It allows you to create mixed objects.

When combining a mixin and a target class, the mixin can add new value to the class in two ways:

  • It can extend the public interface of the class.
  • It can extend or change the behavior of the class.

In addition, the target class can customize the mixin:

  • It can change the behavior of the mixin.

Configuring Mixins

I’ll write a dedicated post on configuration at some point in the future, but let me just enumerate the possibilities, as there are so impressively many:

  • A class can declaratively choose to be extended by one or more mixins.
  • A mixin can declaratively choose to extend one or more classes.
  • An application can declaratively choose to combine mixins and classes.
  • A programmer can – at run-time – choose to combine mixins and classes.
  • Any person can – at deployment time – choose to combine mixins and classes.

(I’m cheating: The last possibility has actually not been implemented yet. But it might be any time. When someone needs it.)

Creating mixed objects

This part is easy. re-motion provides a class called ObjectFactory, which is used to create mixed objects:

MyTargetClass myMixedObject =
  ObjectFactory.Create<MyTargetClass> ().With (x, y, z);

In this sample, myMixedObject is a mixed object, and MyTargetClass is a target class. Oh, names are just wonderful things.

But wait, where are the mixins? And what is that With (x, y, z) method?

The mixins are in the configuration. As I said, I will write a separate post on that topic, but in principle, the Create method will take a look at the current mixin configuration, and it will add all the mixins it finds configured for MyTargetClass, its base classes, or its interfaces.

The With is a wart, unfortunately. Short story: x, y, and z are the constructor parameters for the mixed object, and the With method takes care of their types being respected. (If you are thinking, “Why aren’t they just using a params object[]?” – because that wouldn’t respect the parameters’ types. I’ll explain another time.)

With will soon be replaced by a ParameterList object or similar, so that it will read somewhat like this:

MyTargetClass myMixedObject =
 
ObjectFactory.Create<MyTargetClass> (ParameterList.Create(x, y, z));

I’ll probably write something about ObjectFactory in the future, too, and there I will explain about the With thing.

Extending the public interface

A mixin can extend the public interface of its target class, that’s nice! But what does that mean? It means that a mixin can introduce new methods, properties, and events to the mixed object.

Consider an example I gave in my last post on the topic: a reusable implementation of cloning by means of in-memory serialization and deserialization. If you have such a standard implementation of cloning all wrapped up and reusable, you’ll of course need a public API on your mixed object to actually invoke it. You want to say the following:

object clone = myMixedObject.Clone ();

Where Clone is a method added by the mixin.

And re-motion’s mixin implementation lets you do that! Woo!

However… There’s a catch.

You know, since – as I explained above – the ObjectFactory method effectively checks the current mixin configuration when creating the mixed object at runtime, your computer doesn’t know at compilation time what mixins will be integrated into myMixedObject, or what methods they might add. And, since your computer doesn’t know, the compiler doesn’t either. Now, there are a few programming languages where that doesn’t matter – Ruby or Python, for example. Or Boo. But if you were using any of these languages, you probably wouldn’t be reading this blog post.

Unfortunately, to the C# compiler, not knowing whether a method will exist or not matters a lot. There’s really no good way to combine ObjectFactory’s feature of determining the set of mixins at instantiation time with C#’s need of static information at compile time but one: exploit the dynamic parts of C#’s type system.

“Dynamic type stuff in C#?”, I hear you say, “That doesn’t exist!”

But there is an exception from strict static typing in C#: type casts.

Due to the nature of the .NET (and C#) type system, if you have a reference of static type C, the compiler (generally) has no way to tell whether that reference really holds an instance of C or of a derived type. Therefore, you are allowed to try to cast that reference to another type, and the type check will only be made at run-time. (Now, if that isn’t dynamic…)

So, tough luck with trying to call a method introduced by a mixin on the mixed object; but at least we can cast to an interface introduced by the mixin! If the mixin chooses to add the ICloneable interface to the mixed object, we can write the following:

object clone = ((ICloneable) myMixedObject).Clone ();

This renders the compiler happy, and it does what we want – provided that there is a mixin introducing ICloneable configured for the target class at run-time.

(If you want, note that actually it needn’t be our mixin with the serialization-based cloning, it could be any mixin. You know, this is pretty flexible.)

If you want to save on typing, re-motion’s mixin implementation provides a concept called complete interfaces which allows you to get rid of the casts. But that’s an advanced topic, and I’ll write about it another time. On to the next feature…

Extending or changing behavior

So, a mixin can “extend or change the behavior” of its target class. Sounds… interesting. But how? And… what for?

Well, for the same reason you’d always “extend or change” existing behavior. Does method overriding ring a bell?

Let’s again take an example from my recent post on this topic: you have a finished class model which you need to adapt to a specific scenario (eg. a specific client). For simplicity, let’s just assume a single class PowerfulFoo, which needs to be localized for the German market. Localization consists of adapting the result of ToString by looking it up in a resource file. (Well, it is somewhat simplified, this example.)

With re-motion mixins, the mixin can say, “Override target method – perform base call, localize the returned string, and return localized string.” Not within quotes, and with a number of brackets and semicolons inserted, but essentially, it’s just that.

As you can see, even in this simple example, overriding doesn’t make much sense without calling the base method first – that’s the difference between the “change” (ie. replacing) and the “extend” (ie. adjusting) parts in the feature list. re-motion allows mixins to do both.

Since overriding requires a few explanations, we’ll also keep this for another blog post. But let me add that mixins aren’t only allowed to override methods, but also properties and even events. Any member, as long as it is virtual.

Changing the behavior of the mixin

Consider again the example where we implement cloning in a reusable way. But this time, we won’t go for the slow and embarrassingly simple model of in-memory serialization, but instead, we’ll opt for a more efficient idea: the mixin will simply take all the fields of the cloned object, create a new instance of the object’s type, and copy the field values over to the new instance (optionally calling ICloneable.Clone again, if provided). Simple, and more efficient. At least as long as we don’t have to resort to using reflection to get the fields.

Since the cloning implementation in the mixin should be as general as possible, the question is: How do we get those field values from the mixed object when we can’t make any assumptions about the target class?

One answer is: by providing a template method in the mixin. According to the Web, the template method pattern is used to:

Define the skeleton of an algorithm in an operation, deferring some steps to subclasses.

Which is exactly what we need here – although it’s the target class we want to defer the steps to, not a subclass. re-motion enables the mixin to provide a virtual or abstract member for which the target class can say, “Override mixin member – return my field values.” Again, with more brackets and semicolons, but essentially, it’s that.

Why would you make the member virtual? To provide a default implementation, eg. a retrieve the field values via reflection. That way it isn’t really a template method any longer, more a replaceable default method; but the idea is the same.

So, that was my first write-up about the core features of re-motion mixins. What’s up next? Well, I have a lot of topics to cover now: the details of mixin configuration, ObjectFactory and With, member introduction and complete interfaces, target class member overrides, and mixin member overrides. One of those, it will probably be. Stay tuned.

Written by Fabian

January 14th, 2009 at 4:00 pm

Posted in mixins