Old Pueblo Software

I like the Microsoft implementation of regular expressions in C#. I think they learned from Java’s mistake, and built something a tiny bit cleaner and easier. The key differences are:

• No special static “factory method” needed to create a regular expression
• IsMatch method of Regex class used for quick and dirty searches
• array-syntax “indexer” is used to retrieve results from a match

A brief overview of the regular expression
Let’s say I have a text file that contains key value pairs as quoted values in the form:
key1 = “value1″
key2 = “value2″
…and I want to capture each key and value, stripping out all of the rest of the text. The key has no leading space.

This is exactly the sort of thing that regular expressions are designed to do, in any language that supports them. Here is the regular expression I have set up for this purpose:

^([^=]+?)\s*=\s*["](.*?)["]\s*?$

In Java, one has to use the following objects to create a Regular Expression:

Here is the example in Java:

private static final String REGEX_EQUALS = "^([^=]+?)\\s*=\\s*[\"](.*?)[\"]\\s*?$”;
…
Pattern patternEquals = Pattern.compile( REGEX_EQUALS );
Matcher matcherEquals = patternEquals.matcher( strInput );
if ( matcherEquals.find() ) {
    String key = matcherEquals.group(1); // first match is group 1, not group 0
    String value = matcherEquals.group(2);
    …
}

Here is how this same process is implemented in C#; there are very few differences, but I like the C# implementation a little bit better:

Here is the example using C#.Net:

private static String REGEX_EQUALS = "^([^=]+?)\\s*=\\s*[\"](.*?)[\"]\\s*?$”;
…
Regex regexEquals = new Regex( REGEX_EQUALS );
Match matchEquals = regexEquals.Match(input);
if ( matchEquals.Success ) {
    String key = matchEquals.Groups[1].Value;
    String value = matchEquals.Groups[2].Value;
    …
}

I suppose it isn’t really that big of a change. In Java, you have to use a specialized constructor from the static method Pattern.compile( String strRegex ), while in .Net you just use a regular constructor. But I’ll tell you what — whenever it comes time to use Regular expressions in Java, I am forever returning to the javadocs to figure out how to instantiate all of the objects to make things fit. But here in .Net I see an API that I will never forget. Also, the Regex class has a few nifty methods that I haven’t mentioned here, which are not present in Java, which also make it a good choice when doing really simple searches.

Anyhow, kudos to whoever redesigned the Java Regular Expression API for C# — they did a good job keeping it simple.

C# requires the use of an override keyword in order to implement inheritance. Perhaps this is too obvious, but it is a difference we Java folk will trip over right away. The short description for this is:

In Java, all methods are virtual. In C#, only methods declared with the “override” keyword are virtual.

Presumably, the authors of C# chose the keyword called “override” to promote the idea that the parent object is indicating that it is okay to override this method, and that the child object is specifically saying that he intends to override the method of the parent, and not create another, new method from whole cloth. When taken this way, the Java guy would say this is redundant, because why would both the child and parent need to ask permission? But this is just a facade. In reality, the override keyword is just another virtual keyword, which explains why the child and parent both need to declare it.

I suppose the reason this was done was for performance. There has to be some performance hit to looking up methods in the vtable (or whatever), but what this design lacks in performance it makes up for in lack of confusion. If a Java object implements its own version of a method that has the same signature as the parent, by definition, it is overriding the behavior of that parent method. I am reminded what a friend of mine once said of his computer:

“I intend my servant to do what I say — I do not expect to have to beat him.”

…but that would be the emotional response.

The intended behavior of Java in this respect is well-described with a contrived example from a Football game. Consider the following definition:
public class FootballPlayer extends Player
The Player class defines methods for physics, taking up space on the field, etc. The FootballPlayer class defines legal moves: catching, blocking, hiking the ball, etc — all of the basics. Let’s say that the FootballPlayer object has a method called “BlueThirtyTwo()”, because all football players need to know what to do when they call the “Blue 32″ play. Let’s say for the sake of argument that you didn’t make this method abstract, just to prove a point. In reality you would have made it abstract as a way to force all subclasses to implement it. But that would break my example, so you didn’t do that. You created a new class for each player:
public class SamoanCenter extends FootballPlayer { ... }
public class Quarterback extends FootballPlayer { ... }
public class RunningBack extends FootballPlayer { ... }
…now, each subclass must implement their own version of the BlueThirtyTwo method. This is appropriate, because when the quarterback runs the Blue 32 play, each member of the team has different responsibilites and actions to take, although they have similar properties as FootballPlayer objects.

The expectation in Java is, you can declare a list of FootballPlayer objects, put all 11 of them in an array, and call the BlueThirtyTwo method on each, and each one will take its own BlueThirtyTwo action, and not whatever was defined in the FootballPlayer class.
FootballPlayer center = new SamoanCenter();
FootballPlayer quarterback = new Quarterback();
FootballPlayer leftRunningBack = new RunningBack();
FootballPlayer rightRunningBack = new RunningBack();
// players are all put into a list of FootballPlayer objects called fpList
foreach ( FootballPlayer player : fpList ) {
    player.blueThirtyTwo();
}
In Java, each would invoke his own version of the BlueThirtyTwo() method, as opposed to the parent version, because of the virtual, dynamic lookup which is built-in. In .Net, without using the override keyword, each would implement whatever method was defined in the FootballPlayer object, and not each individual player’s implementation of the blueThirtyTwo method. That’s why the compiler throws a warning message at you — because it correctly detects that you are probably intending to do something that will wind up with unintended consequences.

This example illustrates what the intended behavior of the Java inheritance is, but it can also be easily implemented in C# by including the override keyword, and/or declaring the method as abstract.
public class FootballPlayer extends Player {
    public override void BlueThirtyTwo()
        //do something uninteresting
    }
...
}
public class SamoanCenter extends FootballPlayer {
    public override void BlueThirtyTwo() {
        // hit people
        // look menacing
    }
public class QuarterBack extends FootballPlayer {
    public override void BlueThirtyTwo() {
        // take three steps backward, and throw the ball
    }
}
So, for all you Java guys out there doing work in .Net: remember the override. It makes .Net do what you expected it to do in the first place.

I am a Java guy. Java was the first object-oriented language that I understood, the first one that just did what I expected it to, with very few exceptions. It was the first language that I loved to code in. I understand Java. I breathe Java. Java is my friend.

At my work we are having battles over what programming languages and frameworks to use for internal development. We have a growing list of projects that are coming up, and we are “skilling up” our group to be proficient in one or more languages to support these projects, so the team can have a consistent, interchangeable skill set to work from. We need to make a decision on what language to use.

We have a pretty new guy, a talented and smart person, who is a .Net advocate. He thinks that C#.Net will be useful for almost all of our needs. I’m not so sure. This where the heated debate comes in.

I listed each project that is coming up, and documented the drawbacks and advantages to using one language over the other. Most of these projects proved to be pretty language-agnostic: simple web service apps or web pages that display data to the user in HTML or something. So most seem to be a wash. This means selling Java was pretty easy, because it has mature tools and a vibrant developer community, open standards and our choice of platform to run on. But then, this one, stupid application (the flag ship of our department, actually), came into the fray, and made this argument difficult.

This bothersome application needs to tightly integrate with a potentially arbitrary number of other desktop applications, probably using COM or Windows API hooks, to do a “screen pop” into the other application window, loading customer information or whatever, in response to our application events. So I made a concession on that one: I admitted that since we will need to integrate with other desktop applications in Windows, it stands to reason that we should use a Microsoft technology for that one application. Also, Java has a very nice sandbox model that makes things quite secure, but it also makes tight integration with other Windows applications difficult. So for this one case, C#.Net seemed like a good-enough fit. So this one app could be built using C#.Net.

Little did I know that small concession would take me down a slippery slide into the oblivion that is the .Net framework.

The argument in our team quickly turned from “Java or C#” to “C# for this one desktop application, Java for everything else”, to “C# on the desktop, Java on the server” to “why use Java at all? If we standardize on C# on the client and server, our team will only need to learn one language.”

I am still reeling from the swift decline of the conversation, but fundamentally I had to argue just from what I know, and not using any purely emotional arguments. But how do you measure the impact of working with a technology that you earnestly disagree with, at a fundamental level? .Net goes against several core values.

Anyway, this blog is where I will document some of the issues that have arisen from my move from Java to C#.Net. I hope to publish this internally for my fellow developers at the company. I also hope to use it as a form of documentation, to review the wisdom of this course of action.

Here is the new banner image, with a sepia tone filter applied. I’m not sure I like it better than the original.

Here is the original image:

A flickr user named Jason Thompson graciously provided a great picture of the Tucson cityscape with Creative Commons Attribution license. I cropped the image to use here as the banner. I may eventually modify the color scheme to make it look older (or something). But thanks to Jason for providing such a wonderful picture to the world through Creative Commons.