I Don't Believe In Interface Versioning

I was thinking about how to implement folder recursion for CarbonCopy.NET while taking a shower earlier, and somehow my mind wandered to the topic of interfaces. In. .NET 2.0, I'm told that you'll bee seeing new versions of interfaces implemented like this: IDataReader2 for the new ones, so that old code can still support IDataReader. Does anyone else think this is a really lame way to design an API? What happens when you have .NET 6.0 (VS.NET 13.0 for those of you keeping track) in 8 years.... are we going to have to browse through:

IDataReader
IDataReader2
IDataReader3
IDataReader4
IDataReader5
IDataReader6

and try to figure out which one we want to use? yeah THAT sure sounds like fun. As if I didn't have ENOUGH framework classes that I need to know. Just think of how many Interfaces are present in the Framework. Multiply that by 6 versions, and suddenly you have a whole lot more people coding for Linux.

The Framework has this really neat and elaborate way to extend code through attributes. Isn't there a way that Interfaces could be decorated with attributes that let each inteface declaration know which version of the Runtime it supports? That way, you always get the best support possible for your current version of the Framework, all the time. VS.NET would only show supported items in IntelliSense, and all contracts would be binding, all the time, under one Interface name. The JIT compiler would dynamically create a virtual interface at compile time, under the covers, based on the executing version of the Framework and those attributes.

Is this not an option? Do I just not understand the CLR enough to see why this wouldn't work?

UPDATE: You'd also want custom attributes to set up your own versioning scheme, in case you need to create your own Interfaces for binding in your own code. That way, your custom interfaces don't have to be tied to specific versions of the Framework.

5 Comments

  • That IS extremely lame, but I'd be interested in seeing the MS description of the problem they are solving with this. Versioning is supposed to handled via having different assembly versions you compile against, is it not? I'd rather see people 'forced' to port code to .NET v2.0 assemblies than be 'allowed' to keep an IDataReader compatible with an IDataReader2 in the same assembly.



    Unfortunately MS has a fairly long history of numbered co-versions of APIs from the days of COM.

  • "Does anyone else think this is a really lame way to design an API?"



    Oh, lord, *yes*.



    Oh, dear. Yes.



    Oh, no...

  • It's because they want old code to still be able to run on the new version of the Framework.



    I'm with you... I think it should break and you should be forced to upgrade.

  • An interface is a CONTRACT. If you change the contract, it's a different contract. It's either requiring each application to load it's own version of the framework on the machine (2.0 not being able ot run 1.0 etc), and then in your scheme with 6 versions it becomes unmanageable, or you change the interface and rename it to reflect that.



    I prefer more meaningfull name, like IStatefulDataReader or whatever, or just put the interface in a different namespace with the same name. But I still prefer having IBla2 than IBlaEx which always leads to an IBlaEx2. It's the least evil solution to ensure 1.0 apps to work on 2.0 without having two 20meg downloads.

  • Breaking changes happen between versions, it's just going to happen IRL (forget that it's an interface or abstract class).



    I said I'd *rather* have a breaking change, I didn't say it was ideal. If the interface is truly a contract, then MS shouldn't even consider a new, preferred contract named xxx2. I agree, Sebastian, that they should instead choose a more accurate, focused, meaningful name (IGenericDataReader if they are adding generics for example).



    xxx2 is bad because it says: "We are so creatively bankrupt on naming that rather than pick a name (or namespace) that describes what we are achieving with our NEW interface, we are shoving a breaking change into the same semantic space as the old interface"

Comments have been disabled for this content.