Gaining knowledge is most fun if you didn’t even know you didn’t have it. I guess it’s the surprise principle — the unexpected christmas gift is one of the nicest to get. Suddenly you learn something you didn’t know, or perhaps, if the subject matter is really something you’re very familiar with, it’s rather that you’re suddenly reminded of something you probably new before but had forgotten about. Great!

I just changed the project type of a library of mine to .NET 4 Client Profile. That library implements a type called Tuple. Of course, in .NET 4 they have introduced their own Tuple type, which lives in the ubiquitous System namespace, so I got lots of error messages from a code file that uses the Tuple type heavily. The compiler was wondering whether that Tuple thing in code was System.Tuple or rather FCSlib.Data.Tuple. Oh dear.

Now, it is possible that System.Tuple can be used as a full replacement for my own Tuple. I should check this out in more detail. I’m quite sure, however, that some of the API I created for my own type isn’t going to be there in the standard one, so I’d have to change this as well. Plus, I want to show how to create a Tuple type, not least for those programmers who don’t use C#/.NET 4.0 yet.

So what now? Rename my Tuple to something else? To what? Hm… I was looking around my project for places where I use my Tuple type and suddenly I noticed that I have a file with unit tests for the type, and for some reason I wasn’t getting any error messages for that one, just for the other code file I noticed previously. Weird. Some closer inspection showed that the first few lines of both files differed in an important way. Check it out. This is the file that was giving me errors:

using System;
using System.Collections.Generic;
using FCSlib.Data;

namespace FCSlib {

  public static class CODFunctions<P, R> {
  ...

And this is the file that worked without problems:

using System;
using System.Collections.Generic;
using NUnit.Framework;

namespace FCSlib.tests {
  using FCSlib.Data;

  [TestFixture]
  public class TupleTests {
  ...

You’ve probably noticed it just like I did. In the case that works okay, the using statement for the FCSlib.Data namespace, in which my own Tuple type lives, sits inside my own namespace definition block. This is enough for that statement to have a higher priority when it comes to searching for a type — my Tuple is found before System.Tuple. Exactly what I want, because with the help of that feature, my own FCSlib code can use its own Tuple type without having to rename it or even resort to cumbersome syntax. If I’ve known this before, I have forgotten. Perhaps I never knew. In any case I feel enlightened :-)