Just finished reading this post by Scott Guthrie and was extremely excited to see the new Transparent Intellisense feature in VS 2008. I am constantly vexed when I have to escape out of Intellisense, and this solution looks great.
As for the rest of the post, the VB Intellisense Filtering and C# Using Statement Optimizing are already in place in Resharper, so nothing mind-blowing there. And again I'm reminded how annoying it is that the two languages are diverging further and further from each other. Why can't both languages have those features? How hard would it be to port the Intellisense Filtering to C# and the Using Statement Optimizing into Import Optimizing for VB? Why does VB get cool LINQ Intellisense that C# doesn't get? Little interface things like this seem like such obvious candidates for cross-language compatibility.
Tuesday, July 31, 2007
Friday, July 27, 2007
Fun with Type Inference
Recently a co-worker of mine turned me on to the glories of Resharper. Using Resharper to optimize my code I learned that when calling a generic method, it is often not necessary to specify the type, as the compiler will work it out for you. Aside from a little less typing, I hadn't really figured out how this could be useful. Until this week.
I was writing some basic data layer code, adding parameters to a SqlCommand object. A couple of the annoying .NET/SQL Server 'gotchas' reared their heads at me yet again:
1) You can't stick a null value in as a parameter value, it has to be transformed to DBNull.Value; and
2) You can't stick a date of DateTime.MinValue into a DateTime field.
I wanted a generic function that I could simply wrap all of my parameters into, so that I didn't have to specifically remember "oh this is a date field, call this function" or "oh this variable might contain a null, call this function".
Unfortunately the DateTime comparison can't be used in a generic function, so I needed at least 2 functions, but thanks to overloading and type inference I can still use the same call everywhere. Here are my two functions:
Normally when you call a generic method, you specify the type in the call, such as:
If this were always the case, my calls would differ everywhere, and especially when using DateTime's because the DateTime overload is not generic.
But thanks to Type Inference, I can now write code like the following, without having to care what type of variable I'm dealing with:
I was writing some basic data layer code, adding parameters to a SqlCommand object. A couple of the annoying .NET/SQL Server 'gotchas' reared their heads at me yet again:
1) You can't stick a null value in as a parameter value, it has to be transformed to DBNull.Value; and
2) You can't stick a date of DateTime.MinValue into a DateTime field.
I wanted a generic function that I could simply wrap all of my parameters into, so that I didn't have to specifically remember "oh this is a date field, call this function" or "oh this variable might contain a null, call this function".
Unfortunately the DateTime comparison can't be used in a generic function, so I needed at least 2 functions, but thanks to overloading and type inference I can still use the same call everywhere. Here are my two functions:
Normally when you call a generic method, you specify the type in the call, such as:
If this were always the case, my calls would differ everywhere, and especially when using DateTime's because the DateTime overload is not generic.
But thanks to Type Inference, I can now write code like the following, without having to care what type of variable I'm dealing with:
Monday, July 23, 2007
Fun with Anonymous Methods
A few years back when .NET 1.0 came out, I was presented with a choice: C# or VB? At the time, both languages shared all the same features; if you could do it in C#, you could do it in VB. Another cool thing with the advent of .NET was the fact that a VB assembly could reference a C# assembly (and vice-versa). So, having an extensive background in VB, I decided to stick with what I knew.
Fast-forward a few years. The languages have taken different paths, and with each new .NET release C# got 1 or 2 cool language features that VB didn't have. I kept sticking with my roots, however, and blindly forged ahead as a "VB guy".
This spring, however, I was thrown into the C# world and forced to swim. And you know what? I freakin' love it! I don't plan on ever going back; VB is old and busted, C# is the new hotness.
With all of that said, I've had some learning to do, and some catch-up to play. One of the features of C# that VB did not pick up was the use of anonymous methods. Even after learning about them, I still wasn't sure if I was keen on using them. There were pluses and minuses, and I couldn't decide which out-weighed the other, so I mostly shoved them into the back of my mind and forged ahead in other areas.
All this changed last week. I finally found a slam-dunk place to use anonymous methods: unit tests. By writing the method implementation in-line right into the unit test it can be more immediately clear what the test is doing. Here is a sample:
Don't worry too much about what the test is actually doing, but notice the highlighted part, which is attaching an anonymous method as an event handler. What I like about this is that it makes reading the unit test very clear. You don't have to jump to another function to see what exactly it is doing. I mean, even if you name it well, there is a chance it is not implemented correctly. Putting the implementation right into the test allows someone to easily verify the functionality without jumping around in the code.
Fast-forward a few years. The languages have taken different paths, and with each new .NET release C# got 1 or 2 cool language features that VB didn't have. I kept sticking with my roots, however, and blindly forged ahead as a "VB guy".
This spring, however, I was thrown into the C# world and forced to swim. And you know what? I freakin' love it! I don't plan on ever going back; VB is old and busted, C# is the new hotness.
With all of that said, I've had some learning to do, and some catch-up to play. One of the features of C# that VB did not pick up was the use of anonymous methods. Even after learning about them, I still wasn't sure if I was keen on using them. There were pluses and minuses, and I couldn't decide which out-weighed the other, so I mostly shoved them into the back of my mind and forged ahead in other areas.
All this changed last week. I finally found a slam-dunk place to use anonymous methods: unit tests. By writing the method implementation in-line right into the unit test it can be more immediately clear what the test is doing. Here is a sample:
Don't worry too much about what the test is actually doing, but notice the highlighted part, which is attaching an anonymous method as an event handler. What I like about this is that it makes reading the unit test very clear. You don't have to jump to another function to see what exactly it is doing. I mean, even if you name it well, there is a chance it is not implemented correctly. Putting the implementation right into the test allows someone to easily verify the functionality without jumping around in the code.
Wednesday, July 18, 2007
Leveraging
I don't want to turn this blog into a place where I just dump links to smarter people's blogs, but I haven't posted in awhile and I also don't want this thing to die the death that my first post so accurately predicts. At least not yet.
So here I am, transforming myself into a Link-Whore. I suppose there are worse things, like Assistant Link-Whore. Apparently I'm stealing jokes now too; this will not end well.
Anywho, I came across a blog post today which kind of blew my mind. This is probably basic stuff for a lot of people, but if I can reach even one other guy like me then its worth being called a n00b or something.
The post describes the Big Three higher-order functions: Filter, Map, and Reduce. I've often written the types of methods that these functions clean up, and I've even had the foresight to understand that I was doing the same things over again, and that there had to be a better way. But until today, I've never come across it. Likely I wasn't looking hard enough, which is my bad, but better late than never, as they say.
So here I am, transforming myself into a Link-Whore. I suppose there are worse things, like Assistant Link-Whore. Apparently I'm stealing jokes now too; this will not end well.
Anywho, I came across a blog post today which kind of blew my mind. This is probably basic stuff for a lot of people, but if I can reach even one other guy like me then its worth being called a n00b or something.
The post describes the Big Three higher-order functions: Filter, Map, and Reduce. I've often written the types of methods that these functions clean up, and I've even had the foresight to understand that I was doing the same things over again, and that there had to be a better way. But until today, I've never come across it. Likely I wasn't looking hard enough, which is my bad, but better late than never, as they say.
Subscribe to:
Posts (Atom)