Hangin' with generics

I've been using generics in a project that I'm using on Whidbey. They are tremendously
convenient when you want to use collection classes. That wasn't really very surprising.

What was surprising - mostly because I hadn't spent any time reading the generics
spec - was how useful generic methods would be. For my app, I sometimes needed to
fetch a list of values from a database. I didn't want to write a separate function
for each type,  and with generic methods, I could write the following:

     
public List<T> GetValues<T>(string selectStatement)

    {

     OleDbCommand select = new OleDbCommand (selectStatement, connection);

     List<T> list = new List<T> ();

     OleDbDataReader reader = select.ExecuteReader ();  while (reader.Read())

     {

      list.Add ((T)reader[0]);

     }

     return list;

    } 

I think that's pretty cool. I wrote several functions like that that perform database
operations in a generic (ha ha!) way. So I think generics are going to be cooler than
I expected.

I should mention one more thing. If the type you use in the generic method is one
of the parameters, the compiler can figure out what generic type you're using, and
you don't have to specify it. If I wrote:

         public T Process<T>(T param) {...}
    

I could call it with:

         int i = inst.Process(12);
    

and the compiler figures out that I want Procees<int>.

Oh, and before you ask me for the spec, you can't have it... yet... It's still churning
due to the ECMA process, and we don't want to release it until it's a bit more concrete.