re-motion Team Blog

From the Team

Archive for the ‘mixins’ Category

re-mix has been published on CodePlex

with 2 comments

re-mix (formerly known as re-motion mixins) has been published to CodePlex. The link is http://remix.codeplex.com

Similar to re-linq, the source code repository will still be part of the re-motion project. The source code and binaries of a “mixin release” will be published to CodePlex.

The re-mix page on CodePlex will also contain additional documentation to Mixins.

Written by re-motion Team

April 19th, 2011 at 12:49 pm

Posted in mixins

The art of mixing…

without comments

Hi all, it’s Fabian again. In case you’re interested in learning more about the details of mixins, I’ve started a series on my own blog. For now, it consists of three articles:

The series is bound to grow, so take a look if you’re interested.

Fabian

Update (2011-01-03): All of my blog posts about re-motion mixins can be found here: https://www.re-motion.org/blogs/mix/category/11.aspx.

Written by Fabian

January 14th, 2009 at 4:15 pm

Posted in mixins

Mixins in Domain Design

with 6 comments

Ayende Rahien started a nice thread via his blog entry Aspects of Domain Design. He shows how a rule could be implemented as an aspect (in the AOP sense) that modifies a method. That was an invitation to discussions about whether this should really be done via aspects, and the invitation was well received.

In the comments, I remarked that this sounds much more like multi-dimensional separation of concerns to me. After all, AOP as a paradigm focuses on cross-cutting concerns (like “logging, transactions, security, and caching” – Ayende), but not quite as much on individual types and their semantics.

The notion of multi-dimensional SoC seems to be buried quite deep in the common wisdom of our profession, although there are quite nice implementations, and people can often see the advantages. Still, its status is that of alchemy, only less known. Some people use AOP frameworks or languages for multi-dimensional SoC, and technically, dedicated frameworks for multi-dimensional SoC have a lot in common with AOP frameworks. But personally, I would not like to do much of either using a toolkit made for the other (read more here).

Either way, it’s quite hard to find guidance about how to use any technique for the goal of multi-dimensional SoC. (Ivar Jacobson’s Aspect-Oriented Software Development with Use Cases being a rare exception.) So I thought I’d just start writing about some of our experiences at rubicon with our own mixin implementation.

I always believed that dynamic rule mechanisms should be made explicit where they are to be expected. We created our mixin mechanism to enable 3rd parties to create arbitrary extensions and modifications (notwithstanding the “virtual”-requirement) without modifying our source code or waiting for explicit extension points.

Of course, in a large enough development organization, you have to treat other teams as 3rd parties too, because it becomes just unmanageable to create extension points whenever anybody needs them. For the requesting party that would be pretty tough too, because they would have to live off the trunk and wait for every modification to be designed, implemented, tested and delivered before they can start working.

Using mixins proved to be a panacea for many of those problems. At the beginning, there were several reservations about overusing them, and in fact I’m still not sure how happy I am with the hundreds of mixins that emerged in some projects. But I did eventually give in to the notion that in some cases, explicit extension points would make the system just more fragmented and ad-hoc than using one well-understood paradigm for all of them. It’s still something that needs to be decided on a case-by-case basis, and I’m not sure if Ayende’s example (Account.Withdraw) is a very good one to make that point, at least not without any context.

There’s another example I like for using mixins: parallel class hierarchies.

Here’s the problem: I have an OO domain and a generic UI layer that uses data-binding on steroids. This UI can display icons for objects, but of course it cannot go ask the domain objects. We don’t want UI code in our domain classes after all.

So we have an icon service that the UI can ask for icons. Pseudo code:

interface IIconService
{
  string GetIcon (DomainObject obj);
} 

Now most domain objects just return classname.gif, so this service is easy to implement. But wait, here’s a special rule:

Male and female persons use different icons.

Now we could have an if-statement in GetIcon, but that’s not very OOP. How do we use polymorphism without tainting the domain?

We need another class tree, somehow attached to the original one.

Here’s how this is done using mixins:

namespace Domain
{
  class DomainObject { } // layer super type
  class Person : DomainObject { }
} 

namespace UI
{
  public interface IDomainObjectMixin
  {
    string GetIcon ();
  } 

  [Extends(typeof(DomainObject))]
  class DomainObjectMixin<TDomainObject> : Mixin<TDomainObject>, IDomainObjectMixin
    where TDomainObject : DomainObject
  {
    virtual string GetIcon ()
    {
      return This.GetType().Name + "gif";
    }
  } 

  [Extends(typeof(Person))]
  class PersonMixin<TPerson> : DomainObjectMixin<TPerson>
    where TPerson: Person
  {
    override string GetIcon()
    {
      return (This.Gender == Gender.Male) ? "male.gif" : "female.gif";
    }
  }
}

Now you can cast any DomainObject to IDomainObjectMixin and ask for its icon. The PersonMixin class polymorphically provides its own implementation, while all other types derive the implementation of DomainObjectMixin.

class MyIconService : IIconService
{
  public string GetIcon (DomainObject obj)
  {
    return ((IDomainObjectMixin)obj).GetIcon();
  }
}

I think this leads to a nice separation of layers. Sure, you have to grasp mixins, but you need to understand this concept once, as opposed to understanding a variety of ad hoc solutions. (The use of generics and where-clauses in parallel class hierarchies is a bit ugly, but it follows a simple rule that you can just learn if you don’t want to dig deep and understand why it’s required.) Kind of reminds me of Greenspun’s Tenth Rule, except that a more obvious conclusion from that rule would be to use another language, I guess, but a well-designed framework is still much better than “an ad hoc, informally-specified, bug-ridden, slow implementation” in each project.

There’s another argument I hear a lot that I’d like to address. It goes like this: In OOP, composition is usually preferable to subclassing. That’s not quite true. Subclassing is a very convenient way of gaining a certain set of features (like polymorphism and implementation inheritance), and it would be more than a bit tiresome to do OOP without it. But the more complex a problem gets, the less likely it is that we can solve it just by subclassing. For many problems, single inheritance just won’t do, and multiple inheritance brings its own set of problems. But let me get this straight: yes, we’re trying to make mixins as simple to use as subclassing, so they are easier to learn, and you can apply some of your valuable OOP experience. But the implementation of mixins is basically composition. (There is some sub class generation, but hey, somewhere the composition gluing has to be done.) So the bottom line is, mixins are just classes with a set of composition and delegation rules attached to them. That’s a weird way of thinking about mixins, but the most correct one if you’re reasoning about them in the context of the inheritance vs. composition debate.

- Stefan

Edit: missing reference for Account.Withdraw

Edit: replaced Type Of (T) notation by Type<T> (Left over from an attempt to post this sample to a blog that thinks <T> is an HTML tag.)

Written by Stefan Wenig

November 25th, 2008 at 3:46 pm

Posted in mixins

.NET 3.5 SP1 broke some scenarios for mixins

with 4 comments

OK, first, apologies for not posting for so long. The initial post was triggered by the Lang.NET symposium. We thought it might be a good idea to come forward with a part of our framework even prematurely, because Lang.NET might trigger enough interest. Seems that this did not happen, and since comments were rare, we decided to continue working on some refactorings, extensions and documentation we wanted to get ready before the real launch. Good news: We’re almost there.

SP1 bug for custom modifiers

The service pack that was released yesterday crashes when certain APIs for custom modifiers are called on generic methods of generic interfaces, like IWhatever<T>.Foo<U>().

Fabian posted a connect bug with details, votes are welcome.

Ayende Rahien has the exact same problem with RhinoMocks. Just like Ayende, a non-redistributable hotfix does not seem like much of a solution to us. Even a redistributable one would make the install experience quite cumbersome. I have no doubt that this would be fixed in the next release, but that’d take some time. A hotfix that gets distributed via Windows/Microsoft Update would be great, of course.

No idea what Microsoft can or will do for us here. However, unlike Ayende, we have no problem with using PSS, the risk of getting charged is not really a problem. But first, let’s give them a few days time to handle this via connect.

Here are our options:

  • Find another way to get custom modifiers. That would be great, but it’s quite unlikely that another .NET API, if it exists, would not result in the same situation within the CLR.
  • Use Cecil instead of Reflection. There are a few things we’d like to use Cecil for in the future, but this is not something that we’re going to do tomorrow.
  • Do nothing and have the users worry about any ExecutionEngineExceptions they might get. (This exception will happily escape any catch block.) No way.
  • Disable mixins for this scenario (generic methods of generic interfaces)
  • Not support languages that depend on custom modifiers, like C++/CLI and, according to Ayende, also F# and Spec#
  • Disable custom modifiers by default, so that users of those languages will have to actively enable it in the configuration, and also take full responsibility for making sure they’re using a .NET release that will not crash.

We’re very likely to go for the last option. We might do that in the Castle project, where Fabian is a commiter (the code that actually triggers this bug is in a DynamicProxy method we’re using), someone else might do it before us, or we could re-implement that DynamicProxy method in our own code, if no agreement can be found among Castle developers.

Opinions are welcome.

SP1 serialization bug

Here’s another connect bug: Be careful with static members of ISerializable types. (Be sure to read Höcke’s comment on the validation page, this seems to be worse than it appeared)

This only broke some unit test, and we were able to work around it. Still, I find it remarkable that a Service Pack would introduce two regression bugs that break our code. Then again, we’re doing some weird stuff, especially in the mixin part, and Fabian really went out of his way to make sure he gets unit test coverage for a wide range of usage scenarios.

(Like, we crashed Mono at Lang.NET with a unit test that tested whether deliberately broken user code would trigger the correct CLR Exception. But I guess it’s part of the magic of an event like that when Marek Safar (the Mono C# guy) analyzes this “bug”, Seo Sanghyeon fixes it within minutes, and Miguel de Icaza triages it for backporting to the Mono release that was branched off the day before. Cool stuff.)

We’ve already discovered quite a few bugs in the past, many of them really low level CLR stuff. (We once even reported a security vulnerability in the CLR, I’ll have to go check what happened to that one. No credits yet.)

But discovering bugs during implementation is one thing. The ratio of bugs that get fixed for the next release is quite OK. Discovering regressions is another story, this breaks code that already worked, or is being used in production, and the ripple effects of such bugs, especially in the CLR itself, can be quite horrible.

All this makes me wonder if Microsoft should not want to include our test suite in their build process. Hell, we’d even give it away without source code so they don’t get blinded by LGPL’ed code! ;-)

- Stefan

Written by Stefan Wenig

August 14th, 2008 at 9:09 am

Posted in lang.net,mixins

Lang.NET talk video available

with 5 comments

Hi there as well! I’m Fabian Schmied, also from rubicon.

Today, Microsoft has published the video of the talk Stefan and I gave at the Lang.NET symposium 2008, you can find it here (wmv). In the talk, Stefan explains our original motivation for creating re:motion mixins, our mixin library. I give a technical overview about the library (including a very short demo).

This is just the first post providing some insight about re:motion (especially re:motion mixins), though only indirectly. We’ll give more details, explanations, and samples in the near future. In the meantime, feel free to ask specific questions by posting comments to this blog.

- Fabian

Update 2009-03-23: Updated links to the Lang.NET video.

Written by Fabian

February 20th, 2008 at 1:14 pm

Posted in lang.net,mixins

Introducing mixins (finally)

without comments

Sorry for the delay. After lang.net I spent some time having fun with a bronchitis I caught there (I blame winter-season air conditioning). You can hear it in the talk too, but anyway, here we go.

In the last few months, we have developed a mixin mechanism for static .NET languages, which we’re using with C#. After a few months of internal dogfooding, we’re now ready to release it under an OSS license.

We believe that it provides several useful mechanisms for C# 2.0 and above today. Our mechanism is both powerful and easy to use, syntactically and semantically. We’re using it internally both for typical development problems that would traditionally require duplicate code in C#, as well as for componentized product line development.

Here’s a simple example:

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

public class MyMixin: IMyMixin
{
}

Target t = ObjectFactory.NewObject<Target>().With(); // With provides the constructor arguments 
IMyMixin m = (IMyMixin) t; 

All instances of the target type now implement the IMyMixin interface (as long as they are created via ObjectFactory).

The trick here is that mixins are in reality a composition mechanism, but implementing mixins feels more like inheritance. You define a mixin much like a subclass, and when you use the factory, a subclass is created that does all the composition for you. That gives you most of the power of multiple inheritance (and then some) without its specific problems, like diamond inheritance.

If the target type implements an interface, you can skip the casting by deriving what we call a “complete interface”. (Remember that whatever you might have heard about multiple inheritance, it’s generally assumed to be safe for interfaces.)

public interface ICompleteTarget: ITarget, IMixin {}
ICompleteTarget t = ObjectFactory.NewObject<ICompleteTarget>().With(); 

This is a general property of re:motion mixins: Everything works a bit smoother if you’re using interfaces a lot, but you can always work around it if that is not the case.

Here’s an advanced (if somewhat contrived) example:

public class Target: ITarget
{
  public Target (string name) {...}
  public virtual string GetSomething() {...}
} 

public interface IMixin
{
  void ResetCache();
}

[Extends (typeof (Target))]
public class Mixin: Mixin<Target>, IMixin
{
  private string _cache = null;

  [OverrideTarget] public string GetSomething ()
  {
    if (_cache == null)
      _cache = Base.GetSomething();
    return _cache;
  }  

  void ResetCache()
  {
    _cache = null;
  }
}

[CompleteInterface (typeof (Target))]
public interface ICompleteTarget : ITarget, IMixin {} 

ICompleteTarget t = ObjectFactory.NewObject<ICompleteTarget>().With("stringArg");

This simply creates a mixin that caches the result of GetSomething(). This also points out the difference between mixins and generic AOP mechanisms: An AOP system would allow you to create code that caches every method/property (or lets you choose them based on attributes or regular expressions). Mixins are strictly non-generic. They work on known interfaces and methods, which means that we don’t get the complexity overkill of AOP (but also not the full power of AOP).

(That said, there are ways to use the mixin infrastructure for more generic behavior, but that’s a different story.)

Here’s a short list of features:

  • Create full-featured mixins (implement new interfaces, override virtual methods/properties/events, call “base”-methods, keep state) using the most simple syntax we could possibly come up with.
  • Include one or more mixins from a target type (similar to multiple inheritance) and even override methods of the mixin OR
  • define a mixin for one or more existing types, and just have it magically applied to that type (as long as instances are created via a factory method). You can even create a mixin in a new assembly, copy it into an app’s bin directory and have it picked up automatically, so that existing types just magically “change” (we’re using this for product extensibility and product line development)
  • This even works if you apply multiple mixins to a single target type. If several mixins override the same method, they are automatically ordered based on their dependencies.
  • Automatically implement “complete interfaces”, i.e. interfaces that include members of both target type and mixins, so you don’t have to cast that much.
  • For those of us who use WebForms, which “new” up objects all the time without any chance to use a factory method, there is a special mechanism that replaces the static types in the markup with generated types at runtime.
  • You can apply mixins to any public, non-sealed type, and you may use any type as a mixin. For advanced features like overriding however, the type that does the overriding of course has to be mixin-aware. Also, mixins are easier to use if both target types and mixin types expose their features via interfaces, but this is not a requirement.
  • You can modify the static assignment of mixins to types at runtime.
  • Types with mixins are fully serializable (assuming that all underlying types are).
  • There’s a load of advanced features, like copying mixin attributes to target types, reflecting on mixin types, customizing ordering via dependencies, manually instantiating mixins (behind the scenes, it’s just composition after all), scoped configurations, imperative configuration, parallel class hierarchies between target and mixin types, and type deduction for generic mixin types, to name just a few. For those who really know what they are doing ;-)

This sounds more complicated than it is, in most cases you just write a mixin class, optionally apply a few attributes for overriding, and then specify which mixins you want to use for which target type. We’ve used this library internally now for a few months, and feedback has been very good so far. It turned out that, while started primarily with a focus on product line development, mixins are a very useful general-purpose design tool.

Finally, a word about the preview version you can download from here: It is not yet open source, basically because we didn’t get around to finish all the work we need to do first (license headers etc). Since mixins are only a part of what re:motion is providing, this is quite a bit of work. The other thing is that we’re using Castle’s DynamicProxy library. That’s because Reflection.Emit is a pain to work with directly (mostly because of the less-than-helpful error handling). So we’re using DynamicProxy’s type emitters, but we’re not using its proxy mechanisms. So don’t jump to any conclusions about our implementation just from the fact that we’re referencing it.

OK, that’s it for today, download and have fun!

- Stefan

Written by Stefan Wenig

February 20th, 2008 at 2:54 am

Posted in mixins

Announcing re:motion mixins at lang.net 2008

with 3 comments

Hi there, I’m Stefan Wenig, from rubicon informations­technologie in Vienna, Austria. My coworker Fabian Schmied and I just arrived in Redmond for lang.net 2008. We’ll be introducing a new mixin mechanism for C# on Tuesday, and we’re going to provide some coverage of mixins here. If time allows, we might also blog a bit about other interesting stuff from lang.net, of which there should be plenty.

re:motion is a framework for .NET enterprise applications that we’ve been developing at rubicon for some years now. The mixin mechanism is just one of the libraries it contains, and we’re in the process of moving it all to a OSS development model. If that sounds interesting to you (it should, I promise!), you’ll soon find more information on this blog and on the home page.

This has to be enough for now. Our attendence at lang.net has been on pretty short notice, we left Vienna 22 hrs ago. I’m going to sleep, and tomorrow we’ll have to, guess what, finish our presentation.

The next week will see more blogging about re:motion.

- Stefan

Written by Stefan Wenig

January 28th, 2008 at 8:16 am

Posted in lang.net,mixins