Mixins and Traits

Mixins (I understand them as "composable units of behaviour") are a terribly useful, and as with many other features, once one gets used to them in languages like JavaScript or Groovy, one would love to see them in other languages like C# or Java. Hopefully, the advent of Extension Methods to C# enriched the language to the extent of allowing a form of Mixins.

The problem with extension methods is that as they are nothing more than a compiler trick based on static methods, they don't seem to provide state. Well, I'd never thought much about it, but for some reason I began to ponder on it and came up with a rather simple solution. We could add a static Dictionary<TKey,TVvalue> to the static class containing our extension methods, and we could use that Dictionary as a Register where we could associate state to each object used with our Mixins. Simple, right? I decided to have a look to see what solutions other people have devised to get Mixins with State in C#, and I found this excellent article. It's interesting to see that the guy there came up with just the same solution as me, but with a subtle but fundamental difference, He's not using a Dictionary, but a ConditionalWeakTable<TKey, TValue>

In the .NET Framework 4.0, the ConditionalWeakTable class can be used to associate arbitrary state to any instance. It's thread safe and it keeps a dictionary of weak references from the target instance to its associated state. If a target instance has no references outside the conditional weak table, then it can be reclaimed by the garbage collector. When that happens, its entry in the table is removed.

So yes, after reading the above, I realized using a Dictionary would be quite a bad idea, as it would keep a reference to the involved objects forever, precluding them from being Garbage Collected

It's odd to see how in a time like this, where endless programming discussions about almost philosophical matters like MVC vs MVP vs MVVM fill the net, we find rather common confusion or plain ignorance about some important Computer Science concepts, like Partial functions vs Currying (I already talked about this here) or Mixins vs Traits.

Indeed, I hadn't properly understood the difference between Mixins and Traits until this week, when I came across this excellent article. I used to think the difference lied on them having or not having state. I was quite confused, and both Mixins and Traits can have state, and the differences stem from how clashes between methods are resolved when several mixins or traits are added to a class. With Mixins it's the compiler (or the runtime, think of javascript and object augmentation) who decides which of the clashing methods is selected, while with Traits, it's the user doing the composition who has to take that decision at the time of adding the Trait

With Extension Methods in C# we have a bit of both worlds. If an Object already has a method, and we define one with the same name through an extension method for that type of object, the second one will never be called, it's something that the compiler itself decides and there's nothing we can do with it. Nevertheless, if we have 2 extension methods with the same name that can be applied to an object, we'll get a compiler error (the call is ambigouos between the following...) and using a casting we can decide the method to be applied at that specific case. You can see a sample here, and it's answered/explained here