Showing posts with label C#. Show all posts
Showing posts with label C#. Show all posts

Sunday, September 16, 2007

ScopeGuard for C#

I just found this article by Nicholas Blumhardt at Ubik Systems (http://ubik.com.au/article/named/andreis_scopeguard_for_c). I should let the article talk for itself, but I must say something about it first.

What is it? It’s kind of a generic transaction engine. This means that if you have very important piece of code that must not alter the state of your application if not completed, then you can define steps to roll everything back.

How does it work? Simple as igneous, anonymous functions is stored up in an array as your code runs along. When the code hits an exception, each of the functions is executed in “Last In First Out” (LIFO) order. Everything is implemented in a single class called Guard.

I am fond of code that clearly defines the happy execution path. This solution will mess up the happy path and obscure the original intension of the code. However, this is a simple and creative solution to a tough problem.

Finally, those guys over at Ubic is really bright, you should read all of their articles and check out their projects aswell.

Saturday, September 15, 2007

What will the others think?

So in my last post I lightly shared some of my philosophical thoughts about generics. I can't say that I really understand what I’m on about in that post. However there is a lot of stuff that could be done to the most common languages out there. What I like about C#, is the fact that Microsoft continue to develop the language. This encourage the thought that we might have a really good programming language some day.

All of this is interesting, and I am always interested in ways to better my code. New syntax gives me more power and possibly new ways to design and write better code. So I am a coding geek, but I am also a professional. S0 when someone tells me that functional programming will improve my code and make it easier to maintain, then I can agree with that person to a certain level. Now, some of you might think that I am stupid to agree to this only “to a certain level”, but most programmers isn't interested in experimenting with new syntax that they feel uncomfortable with. And they usualy state that the way they've always solved problems work, changing it will only introduce more risk then reducing.

So what will happen when we enter the full blown era of C# 3? Well I will of course take advantage of this in my design. And I will probably write the toughest parts in our projects myself, but what will happen when one of the other programmers must put a lambda expression into a method call that I have written? I think they will question my thinking. It doesn’t matter what I think, they are content with how they solve problems already.

Let’s face it, functional programming and full blown utilization of generics turn object oriented programming on the edge. It’s totally a new way of thinking. And I don’t think that many programmers out there are ready for it, or even interested in getting ready for it.

My final point is that when I act system architect, I also have the competence of my collegues in mind. Not doing so will risk the time frame of the project. But keep in mind that I also have their personal education to think about. There must be balance.

Friday, September 14, 2007

Generics C# 2.0

I'm not an experienced programmer when it comes to generics. I thought that I was. However, the more interested I get in programming languages, the more I tend to look at other languages. Now I realize C# 2 is limited.

Disclaimer: Understand that I limit my discussion to C# 2 as reference, I haven’t checked out C# 3 fully just yet, so I will not even bother stating anything about it. Also realize that this particular subject isn't my primary. Johan (blog in Swedish http://hoomla.blogspot.com/), a friend of mine introduced me to the mysterious world of questioning why languages look the way they look. I find myself thinking in other patterns now days, that’s all. So I have some thoughts that I want to put down.

You all know how List<> work, you declare your List<> and give it a type to adopt. Then we have Dictionary<,> where you define two types that you want the class to adopt. Both are good, you can do great stuff with these things. But what if you could declare something like an Array<Tn> where n is a variable number of T’s. Example, I want an Array that holds two strings and a integer, then I would do this Array<string, string, int>. Or if I wanted an Array with one string, one integer and MyType, then I would declare it Array<string, int, MyType>.

As far as I understand, some languages have support for this, it’s called Tuples. F# has Tuples, I haven’t investigated if it is what I think it is just yet. So how would we go about using this generic generics then? What would a foreach look like? I don’t know, could we use foreach or should we need to use more functional programming?

However, generics aren’t limited to arrays or lists. That’s just the most obvious reason to use them. FPSharp is a great example of what you can do with generics (http://sourceforge.net/projects/fpsharp). Credit goes to Johan who find and investigate tons of these things every day.