Toluu

CodeThinked

codethinked (kōdthĭngked) adj. To be consumed by or obsessed with code.

Emergent ComplexityNovember 17

This weekend, after the Raleigh Code Camp, James Avery put on an Open Spaces conference called Shadow Camp. It was a small group of people who came together on Sunday morning to discuss the topic of complexity in software. While people were discussing topics for the different slots, one of the topics which was suggested by Corey Haines was "Emergent Design". The idea of Emergent Design is not a new one in the agile world, but discussing this in relation to software complexity led to an interesting discussion on entropy in software.

For many people the idea that complexity is emergent may sound like an obvious statement. We all know that from the second law of thermodynamics that all systems trend toward chaos, but we think of those systems as uncontrolled natural systems. We don't think of our software as a natural system with forces that are out of our control which changes and evolves on its own. But our software is constantly changing and evolving in ways that are more than the sum of the changes we put into it. Every time a developer touches a piece of code, the design of the system becomes more divergent from the

IronRuby talk at Raleigh Code Camp This WeekendNovember 13

I am giving a talk on IronRuby at the Raleigh Code Camp this weekend. It is titled "Microsoft and Ruby Sittin' in a Tree" and is basically a 100-200 level overview of Ruby along with a few IronRuby specifics such as .net integration.

If you are at the Raleigh Code Camp, and you don't suck, then you should come check out my talk!

C# 4.0 New Features Part 4 - Generic ContravarianceNovember 11

Here are the previous parts to this series:

Part 1 - Dynamic Keyword

Part 1.1 - Dynamic Keyword Second Look

Part 2 - Default And Named Parameters

Part 2.1 Default Parameter Intrigue

Part 3 Generic Covariance

I went on a serious blogging streak, and then all the sudden I just dropped off with my C# 4.0 new features series. I guess that just goes to show you that I need to spread this stuff out! Anyways, I am back today with part 4 of this series on generic contravariance. This post is actually probably going to be pretty short, because contravariance is a topic that is very similar to covariance, but it also isn't really all that interesting. It can be quite useful though, and that is why I am bringing it to you here.

In the last post we created an interface that looks like this:

public interface IContainer<out T> { T GetItem(); }

With this

C# 4.0 New Features Part 3 - Generic CovarianceOctober 31

Here are the previous parts to this series:

Part 1 - Dynamic Keyword

Part 1.1 - Dynamic Keyword Second Look

Part 2 - Default And Named Parameters

Part 2.1 Default Parameter Intrigue

When generics were introduced in C# 2.0 they were one of the best features that ever came to C#. Anyone who had to create strongly typed collection classes in C# 1.0 knows exactly how much code generics saved us from having to write. The problem though is that generics don't seem to follow the same rules of inheritance that all of the other classes follow. Let's start off by defining two quick classes that we are going to use for the rest of this post:

public class Shape { } public class Circle : Shape { }

Here we have our stereotypical class hierarchy, which is not doing anything currently. But the behavior of these classes is not important. Now, lets define a dummy container class that can hold an instance of any class:

public interface IContainer<T> { T GetItem(); } public class Container<T&g

C# 4.0 New Features Part 2.1 - default parameter intrigueOctober 30

With all of the new C# 4.0 stuff coming out, I feel like a kid in a candy store. Sorry for post overload, but I just can't help myself! I also think I need to stop putting numbers on these posts, because obviously I have just completely thrown them to the curb. I hate to put a "Part 3" on this post though, since it is just an extension of a previous one.

Jonathan Pryor pointed out on my last post that the default parameter feature in C# 4.0 was implemented in the same way that that the default parameter feature in VB.net has been implemented. He also points out a seemingly obvious way that they could have made it better, but then he points out why it wouldn't work when combined with the named parameter feature.

So, since Jonathan is a freakin' smart guy, and most of us (including me) aren't that smart, I am going to elaborate on his comment and explain in detail what he is talking about.

So, to start off let's look at the implementation of default parameters in C# 4.0. It all starts with two attributes called OptionalAttribute and DefaultParameterValueAttribute. If you go look these attributes up, you will see that they have been around since since .net 1.1 and .net 2.0 respectively. The reason for this is that other languages besides C# have supported these features going back to .net 1.1. In fa