Tuesday, June 17, 2008

VB.NET Optional parameters

First of all, let me state: I’m not much of a VB fan. However, the company where I’ve worked for about 8 months had everything implemented with VB.NET (for compatibility reasons – they came from a VB6 era) and I had to get used to it. It wasn’t hard, but I definitely prefer other approaches, like C++ or C#.

But there was one little thing that I enjoyed in VB.NET: optional parameters. Take a look at the following example, specially the doSomething method:

(click to enlarge)

The second parameter is optional. That is, if you don’t specify it in a method call, the compiler (remember, the compiler!) inserts the "False" string for you. If we look at the generated IL, we can see that there’s a false string inserted when we call the method with just one parameter. Despite I wrote different calls to the method, the generated call is exactly the same:

(click to enlarge)

Also note that I only wrote one method and, accordingly, only one got generated by the compiler. However, the C# (3.0 and below) compiler doesn’t allow this. To do the same example with C#, we’ll need to write two methods and take advantage of the method overload:

(click to enlarge)

Looking at the generated IL, we’ll see the difference:

(click to enlarge)

Now, the compiler emits the call to different versions of the same method. Of course, two methods were generated. So, why do I like optional parameters?
Well, as you may have noticed, in the C# example I had to wrote two different methods to do the same. And this is the main reason why I think optional parameters are nice. I “googled” a little to find why the C# team decided to keep this feature out, and found a few “pros and cons”:

  • Using optional parameters will allow programmers to write less code. Less generated methods.
  • It’s intuitive.
  • COM interfaces are filled with default parameters (for example, the Microsoft Office COM automation model - some functions have as many as 30 default parameters). This makes it hard do work with C# (you need to specify all the parameters).


  • A change in the default parameters will force the user to recompile (imagine if the default parameters change in a server, the client has some troubles).
  • The code generated by the compiler is less obvious (the user didn’t write it).
  • Microsoft tries to limit “the magic” because it’s harder to follow up by programmers.

Optional parameters are not CLS compliant. However, in my opinion, I think it would be good to have them in C#. We had default values in C++, optional parameters exist in VB.NET… We should have them in C#.

I don’t think though that they will ever exist in C#. I’m not seeing it in the near future.

Discussion about this issue:


Note: The C# 4.0 will allow optional parameters.

Monday, June 16, 2008

The Listen Activity Issue – State Machines

In the past couple of months, I’ve dedicated an amount of my free time to learn Windows Workflow Foundation. The Workflow concept was familiar to me and I was curious about this technology. So far, and there’s only been 6 months since I started this learning, I got to apply this technology a couple of times.

Why am I writing this post? Well, from all of the scenarios I came across until now, one of the most “tricky” ones is when there’s a timeout situation. Let me explain:

One of the most common issues every programmer has to deal with is the timeout situation. This situation happens all the time, whether it’s on a synchronous/asynchronous request, a lack of user intervention or even a hardware failure. What to do when there’s no response from a server? Should we wait for ever? Of course not: it’s a timeout!

Up until now, to deal with this, we’d probably implement a timer and when the time to wait for a response has ended, we should perform a set of actions to compensate this event (e.g.: Cancel the asynchronous request – most common). With Workflow Foundation, a good part of all the work needed to do this is already done! The Listen Activity:

The above picture shows the Listen Activity. What is it? Well, it’s a “block” that waits for “n” events and when one of them fires it resumes execution, going down the trail of the event that fired. The other ones are no longer to be “listen”. One of the events can be a delay (a.k.a. timer). Are you already picturing the “timeout situation”? It’s perfect! One event (or more) is what our application wants (e.g.: A document approval from a user) and the other event is the timeout!

So, why am I complaining? Well, the listen activity is available only for Sequential Workflows. That is, workflows that execute the activities sequentially and the execution of them can’t go back. My loved listen activity can’t be used on State Machine Workflows. According to Kenn Scribner, a software architect and instructor at Wintellect, who wrote Windows Workflow Fountation Step by Step, WF team decided to keep the listen activity out from state machine workflows because it could be a potential cause of deadlocks (witch are not easy to find). I can agree that it could lead to these “tricky” deadlocks, I can even imagine a few ones and tell you how to solve them (don’t ask), but one thing that I can’t understand is why aren’t we able to decide if we want the risk. I mean, we become software engineers for a reason! Solve complicated problems! To come up with solutions for the “hard stuff”!

Well, of course Microsoft doesn’t do things for no reason, and you can “go around” and implement the listen activity yourself (composite activity) or even use Parallel activity. But this is unnecessary work if we had the listen activity. I sure hope they’ll let us use the listen activity with state machine workflows in the next WF release.