Mixins and C#

In one of my previous lives when I first heard about mixin and tried to look it up I hit into various conflicting definitions. The definition of Mixin I settled for is “MixIn programming is a style of software development where units of functionality are created in a class and then mixed in with other classes“. In C++ two common ways of doing this is multiple-inheritance and parameterized Abstract Sub Class (yep not Abstract Base class). I’ll not get into MI because the basic design of C# will never allow it. However C# may be expanded to include Mixin using generics.

Mixin in C++

The definition of mixin above is pretty general. Even though mixin is a class it is intended to be combined with other classes and not to be used standalone. Mixins can be defined using parameterized inheritance of Abstract Sub class as follows

template <typename Base>

class MyMixin : public Base



template <typename Base>

class AnotherMixin : public Base




MyMixin<AnotherMixin<string> > mm;

In the above code both MyMixin and AnotherMixin derive from the type parameter passed to it. They are Abstract Sub classes because their super classes are not pre-determined. It is possible to chain them to create a singly-inherited hierarchy so that the combined class gets the public functionality of all the mixin classes in the chain. Lets take a look at a more concrete example….

#include <iostream>

#include <string>

#include <ctime>

using namespace std;


template <typename T>

class AgeProvider : public T


time_t createdOn;


AgeProvider() {



double age() {

time_t currTime;


return difftime(currTime, createdOn);


string CreatedOn () { return ctime(&createdOn); }



template <typename T>

class CountProvider : public T


static unsigned counter;


CountProvider() {



unsigned GetCount() {

return counter;



template<class T> unsigned CountProvider<T>::counter = 0;

AgeProvider<CountProvider<string> > TrackedString;


int main(int argc, char* argv[])


AgeProvider<CountProvider<string> > tstr;

tstr.append(“Abhinaba “);


cout << “Content : “ << tstr << endl;

cout << “Created : “ << tstr.CreatedOn();

cout << “Age : “ << tstr.age() << endl ;

cout << “Count : “ << tstr.GetCount() << endl;

return 0;


Here the first mixin class in AgeProvider which gives info on the age in seconds of an instance of the class as well as when the instance was created. The other mixin is CountProvider which gives how many instances of a specific class was ever made. Both of these classes have no use on their own. However when they are mixed together with a stand-alone class like string they provide the funtionality of counting and age to that class. Interestingly the whole of the above works without any multiple-inheritance and not imposing any restriction on the Mixin classes on what they inherit from or the inheritance order.

Mixins In C#

Some suggest that extension methods in the upcoming C# 3.0 are a kind of Mixins, because you can put in functionalities in these methods and arbitrarily tag it onto any class you want. In the C# 2.0 specification section 20.1.3 it is clearly called out that the base class of a generic class has to be a constructed class type so this rules out using the above approach to be used in C#. I am not too sure on why we choose to explicitly disallow abstract subclass. Since C# does not support multiple-inheritance, IMO it should have supported Mixin style coding.

Comments (8)

  1. Anonymous says:

    I would dearly love to know the reasoning behind disallowing abstract subclass, since it is such a useful feature.

    Other approaches, such as an implicit cast operator, fail because you can use interfaces on implicit cast operators.

    You can also see my prediction about Mixins in C# 3.0, but the problem with that is that it can’t save state on the object lever easily.


  2. IMO extension methods is not a way for mixin, simply because there is no straight-forward way to store state.

    Moreover, the C# design team is always suggesting against the usage of extension methods. Ext methods were introduced to support LINQ and used outside of that poses namespace pollution problem. As the method names are directly used and their encapsulating static classes are ignored.

  3. Anonymous says:

    If my assumptions are correct, the C++ style (when applied to C#/.NET) mixin would not work in a situation where the generic type is sealed.

    If that assumption is correct, then I would find extension methods far, far more useful in everday coding — warts (namespace pollution, syntax) and all.

  4. If the class is sealed then you cannot add it to a mixin as Mixins need to inherit from the class. As I said Extension methods cannot solve this problem. Lets consider the example I used of AgeProvider. This class needs to store the state information of when the object was created. You cannot do this with extension methods without significant hacking.

  5. Anonymous says:

    I shouldn’t read and then post too quickly. 🙂

    Yes, it’s clear now why mixins would be preferable over extension methods.

    One of the reasons I was biased toward extension methods was that I had hoped to turn my static helper classes into more useful entities. Many of them fit right into the pattern for extension methods.

  6. Anonymous says:

    There are two reasons why we chose not to suppose mixins in the style of class C<T> : T. The first is that the language design involved is not trivial. Unlike C++ templates, we wanted to be able to type-check generic definitions separately from their uses. So in a definition such as

    class C<T> : T {

    virtual void Bar(T x) { x.M(); }

    override void Foo() { }


    we must specify somehow that T has a method M, and also a method Foo that can be overridden. Furthermore, we wouldn’t want Bar to accidentally override a method Bar, if one existed in T, and to define a new method Bar, otherwise. One way round these problems is to specify a constraint on T, and use the "new" keyword to ensure that Bar really is fresh:

    interface I { void M(); void Foo(); }

    class C<T> : T where T : I {

    new virtual void Bar(T x) { x.M(); }

    void I.Foo() { }


    The second obstacle is CLR implementation. If code were always specialized (as in C++ templates), then this style of mixin just "drops out" of the implementation. But we attempt to share code on reference instantiations. Consider

    class C<T> : T {

    int f;

    int M() { return this.f; }


    How do we JIT-compile the field access? At JIT-compile-time, we don’t know the offset of f, because that depends on the layout of T, which typically is different for distinct reference-type instantiations of T. A similar problem affects vtable slots. These problems aren’t insurmountable – we could use some kind of execution-time offset/slot lookup, similar to that used for runtime types, but it’s all additional complexity for the CLR.

  7. Andrew thanks for the information. I think we must do something more for the first issue. Very much like C++’s upcoming concept feature we should pull out of constraint specification by derivation hierarchy and use generic ways of specifying constraints. See http://www.artima.com/cppsource/cpp0x2.html

    The second pointer is an eye-opener thanks for this. I can now see why Type parameter used as base type will pose serious issues with code-sharing. Using lookup to locate offset at execution time will burden the system even more. Since Mixin are not mainstream scenario we shouldn’t be perf compromising the system for this….

  8. remix@codeplex says:

    extension methods do not allow to store states. Therefore they are no real implementation of mixins.

    On http://remix.codeplex.com there is an open source framework that  brings mixins to .NET.