Ayende @ Rahien

Refunds available at head office

MEF & Open Generic Types

I read Glenn' s post about MEF's not supporting open generic types with somewhat resembling shock. The idea that it isn't supporting this never even crossed my mind, it was a given that this is a mandatory feature for any container in the .NET land.

Just to give you an idea, what this means is that you can't register Repository<T> and then resolve Repository<Order>. In 2006, I wrote an article for MSDN detailing what has since became a very common use of this pattern. Generic specialization is not something that I would consider optional, it is one of the most common usage patterns of containers in the .NET land. IRepository<T> is probably the most common example that people quote, but there are others as well.

This is not a simple feature, let me make it clear. Not simple at all. I should know, I implement that feature for both Object Builder and Windsor. But that is not what I would consider an optional one.

I am even more disturbed by the actual reasoning behind not supporting this. It is a technical limitation of MEF because internally all components are resolved by string matching, rather than CLR Types. This decision is severely limiting the things that MEF can do. Not supporting what is (in my opinion) is a pretty crucial feature is one example of that, but there are other implications. It means that you can't really do things like polymorphic resolutions, that your choices in extending the container are very limited, because the container isn't going to carry the information that is required to make those decision.

I would advice the MEF team to rethink the decision to base the component resolution on strings. At this point in time, it is still possible to change things ( and yes, I know it isn't as easy as I make it seems ), because not supporting open generic types is bad, but not having the ability to do so, and the reason for that (not keeping CLR Type information) are even worse. I get that MEF needs to work with DLR objects as well, but that means that MEF makes the decision to have lousier support for CLR idioms for the benefit of the DLR.

Considering the usage numbers for both of them, I can't see this being a good decision. It is certainly possible to support them both, but if there are any tradeoffs that have to be made, I would suggest that it should be the DLR, and not the CLR, which would be the second class role.

Comments

zihotki
03/22/2009 06:27 PM by
zihotki

It seems to me that I have a déjà vu. Situation with EF was very similar to this..

josh
03/22/2009 09:47 PM by
josh

I saw Glenn's post and some tweets between you two while on vacation this week. But I glossed over the details and implications because my mind was elsewhere, only thought that it was surprising. I thought Glenn's explanation was reasonable, and you're concerns are too. I probably won't get the impact until I use MEF.. or my brain goes back into full time work mode.

Glenn Block
03/23/2009 03:20 AM by
Glenn Block

@Oren

I do understand your concern, and appreciate the feedback. Personally, I am a big fan of generic specialization :-) My post was meant to be factual and explain why things are the way that they are currently.

Based on our discussion, I wil be talking to the team and we will see what if anything we can do to further bring type into the picture. We have already made a bunch of changes in our forthcoming drop to allow contract binding to be stronger and include type information. We may be able to take this even fruther.

Thanks

Glenn

@zihotki can you clarify this statement? How is this similar?

Comments have been closed on this topic.