Thursday, December 11, 2008
Saturday, December 6, 2008
Thursday, December 4, 2008
Sunday, November 23, 2008
Thursday, November 20, 2008
Thursday, November 6, 2008
Thursday, October 9, 2008
Friday, September 12, 2008
Friday, August 29, 2008
Wednesday, August 20, 2008
Monday, July 21, 2008
Wednesday, July 16, 2008
Wednesday, July 2, 2008
Tuesday, June 17, 2008
(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:
Monday, June 16, 2008
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.