History lesson: Anders was lured away from Borland by Microsoft with a hefty offer of a $1.5 million signing bonus, a base salary of up to $200,000, and options to buy 75,000 shares of Microsoft stock.

Looks like it was worth it, as each C# release has added many interesting and powerful features, while maintaining a fine balance between complexity and simplicity.

GetName

Why does GetName return null for any integral type you pass it except those that correspond to a constant?

For example, this is completely valid:

enum Fruit : byte { Apple, Orange, Cumquat };
var fruit = Enum.GetName( typeof(Fruit), ulong.MaxValue );
// fruit now equals null

In every other case in the Enum class where you pass an integral value outside the range of the underlying type, you get an exception. Except here.

IsDefined

Why does IsDefined throw an exception when you pass it an integral value that can be safely narrowed to the enumeration’s underlying type?

For example, this will throw an exception:

enum Fruit : byte { Apple, Orange, Cumquat };
var defined = Enum.IsDefined( typeof(Fruit), 0 );

Why? Because it’s a integer literal (and therefore type int) and the underlying type of Fruit is byte. This would be alright if this is how the Enum class consistently treated this case, but it’s not. In every other method, the Enum class is OK with you passing in an int value for a byte enumeration (as long as it’s within the range of the underlying type).

ToObject

Why does ToObject silently overflow for values outside the range of the enumeration’s underlying type?

For example, this code will give the following non-intuitive result:

enum Fruit : byte { Apple, Orange, Cumquat };
var apple = Enum.ToObject( typeof(Fruit), 0 );
var elppa = Enum.ToObject( typeof(Fruit), 256 );
Assert.AreEqual(apple, elppa);

Assuming that we ignore the fact that silently overflowing is typically a bad idea, this is again completely inconsistent with the rest of the library. Why overflow here, but not in GetName?

Conclusion

The .NET Enum class is not lacking in it’s ability to extract any information you need from an enumeration. It is, however, a little inconsistent in terms of how it treats underlying type mismatches, overflows and narrowing conversions. Barring a new, generified Enum class from Microsoft, the best way to deal with these inconsistencies is to either be aware of them, or use a third-party library to hide them.

(Edit: Some people have noted that my conclusion was a bit weak and preachy towards Dnum, which I have to admit is not without truth. I’ve seen edited it. For the record, the old conclusion was: “Fortunately, these and other problems have been fixed in my Dnum library, which should be released in the next couple days. Be sure to check it out.”).

Furthermore, after some thought, I’ve decided to split up Fep arrays. In PHP arrays aren’t really arrays in the traditional sense, but more like array/associate array hybrids (JavaScript uses a similar concept). This can be confusing, error-prone and I don’t think that the benefits of having an hybrid array system outweighs the complexity.

Thus, in Fep, there will be two main collection types: lists and dictionaries. Here’s how a Fep list will look like:

// Fep
fep = [ "foo", 1, 2, "bar" ];
fep.count(); // == 4
fep.add( "baz" );
fep.find( x => x > 1 ); // == 2
 
// Will compile into this PHP
$fep = new FepList("foo", 1, 2, "bar");
$fep->count();
$fep->add( "baz" );
$fep->find( function( $x ) { return x > 1 } );

And here’s how a Fep dictionary will look:

// Fep
fep = { blah: "blah", foo: "bar", 0: "zero" };
fep.keys(); // == [ "blah", "foo", 0 ]
fep.containsKey( "foo" ); // == true
fep.remove( "foo" ); // == true
 
// PHP
$fep = new FepDict(array("blah" => "blah", "foo" => "bar", 
         0 => "zero"));
$fep->keys();
$fep->containsKey( "foo" );
$fep->remove( "foo" );

Today, I’m going to take a look at an variety of programming tasks and show how they are done in both Java and VB.NET (the .NET 1.1 version). Since both these languages have differing feature sets, I’ll try to only use features that both the languages have, in order to compare them fairly. I know this might misrepresent the complexity of the languages, and I’m cool with that. The purpose of this post is merely to explore and discuss the syntax of each language.

Collections

Creating and manipulating collections is a common task in procedural programming languages, so let’s look at that first. Consider arrays. To make an array of 10 String objects in Java, I would do this:

final int ARRAY_LENGTH = 10;
String[] arr = new String[ARRAY_LENGTH];

In VB.NET, things get a bit more complicated, but for the most part, you’d do something like this:

Const ARRAY_LENGTH As Integer = 10
Dim arr(ARRAY_LENGTH - 1) As String

Woah, what? Why is it ARRAY_LENGTH – 1? That’s because VB.Net is an evolution of VB6, and in VB6, for reasons unknown, the value in the parenthesis is not the number of elements but instead the maximum index. There’s a second way to create arrays in VB.NET using anonymous arrays:

Dim arr() As String = New String() { "foo", "bar" }

You may also create arrays using anonymous arrays in Java:

String[] arr = new String[] { "foo", "bar" };

Now let’s look at something a bit more powerful: the ArrayList. Both Java and VB have a version of this class with more or less the same syntax. Let’s use them in a real world situation. Consider this task: We have an ArrayList with a bunch of Strings and we want to join them together using a comma. Here’s the code to do that in VB without using generics:

' Option Strict is On (as it should be).
Dim list As ArrayList = New ArrayList
list.Add("a")
list.Add("b")
list.Add("c")
 
' Create the comma-joined string.
Dim str As String = String.Join(",", _ 
    DirectCast(list.ToArray(GetType(String)), String()))

That’s quite a jumble at the end there. Let’s see we would do it in Java (again, without generics):

List list = new ArrayList();
list.add("a");
list.add("b");
list.add("c");
 
// Create the comma-joined string.  Let's assume that we've 
// created a method called join(String str, String[] strList) 
// that acts the same as .NET's String.Join().
String str = join(",", (String[]) list.toArray(new String[0]));

(Aside: Anyone familiar with generics is probably beating their head against their desk. This example is just screaming for it. I’ll include the generified version of the Java example at the end for the curious.)

Same problem in Java. Converting from an ArrayList (or any Collection for that matter) does not look pretty (and is somewhat complicated for a novice programmer), even though it doesn’t seem like it’s a lot of ask. We have a collection of things, and we want to put them into an array, which is a very basic type of a collection. What’s the problem?

Basically, it has to do with the programming language not knowing what’s in the ArrayList. If we just wanted to convert to an array of objects, that’s no problem:

// Imagine we still have the "list" object 
// from the previous example.
Object[] objArray = list.toArray();

This works because the programming language can be sure that all of the items in the ArrayList are at least Objects. Unfortunately, in most cases, that’s not especially helpful. Fortunately, both these languages have a solution to the problem and that’s telling the programming language that the ArrayList is an ArrayList of Strings. The technology that does that is called generic programming.

That’s it for today. In part 2, we’ll delve deeper into the wordiness of VB.NET and how it drives you nuts if you program with it on a regular basis. Here’s the generified version of the Java program for the keeners:

List<String> list = new ArrayList<String>();
list.add("a");
list.add("b");
list.add("c");
 
// Create the comma-joined string.  Let's assume that we've 
// created a method called join(String str, String[] strList) 
// that acts the same as .NET's String.Join().
String str = join(",", list.toArray());

The String Concatenation Approach

Whatever your reason is for generating HTML, the best bet is your first prototype looked something like this:

(Aside: All this code is in VB.NET… the original VB.NET (i.e. not 2005 or later). It also assumes ASP.NET 1.1. This is because the client I work for still uses this technology, so all my experience is with it. The code should still be fine though, as all versions of .NET after 1.1 are more or less backwards compatible.)

' Run some query on the database.
Dim dataTable As DataTable = Query()
 
' Dump it into an HTML document.
Response.Write("<html>" + Environment.NewLine)
Response.Write("<head><title>Database Table</title></head>")
Response.Write(Environment.NewLine)
Response.Write("<body>" + Environment.NewLine)
Response.Write("<table>" + Environment.NewLine)
 
' Print the rows.
For Each row As DataRow In dataTable
  Response.Write("<tr>")
  ' Print the cells.
  For Each item As Object In row
    If IsDBNull(item) = False Then
      Response.Write("<td>" + CStr(item) + "</td>")
    Else
      Response.Write("<td>&nbsp;</td>")
    End If
  End For
  Response.Write("</tr>")
End For
 
Response.Write("</table>" + Environment.NewLine)
Response.Write("</body>" + Environment.NewLine)
Response.Write("</html>" + Environment.NewLine)

Now don’t get me wrong, this code will do the trick. But as you write it, you start to feel a bit dirty. HTML is a language for representing hierarchies, yet you’re concatenating strings. You start to feel like there’s a more elegant way to do it, a way that takes advantage of the structure of HTML.

And there is.

The Programmatic Approach

Ok, so we want to take an approach that has some knowledge of the HTML we’re writing. Enter XML. .NET uses XML for, among other things, it’s Javadoc-like documentation generator and it’s ASP.NET config files. With XML so prevalent in .NET, it’s not surprising to discover that it’s part of the standard library, in the namespace System.Xml.

So you’re thinking “Cameron, who cares about XML, I want to make an HTML document!” Gear down, sugar plum, XML can still help! As you may or may not know, HTML (at least the XHTML dialects) is a reformulation of XML. That is, an XHTML document is an XML document. As a result, we can use .NET’s built-in XML support to generate an HTML document.

Thus, if we want to write the same code in previous example in .NET XML, we would do the following. First, we would need to make a new XML document. That’s easy enough:

Imports System.Xml
 
' Create a new XML document.
Dim xmlDoc As XmlDocument = New XmlDocument

Now we want to start writing some HTML. So let’s create our html tag and add some headers.

' Create the html tag.
Dim xmlRoot As XmlElement = xmlDoc.CreateElement("html")
xmlDoc.AppendChild(xmlRoot)
 
' Create the head tag and append it under the html element.
Dim xmlHead As XmlElement = xmlDoc.CreateElement("head")
xmlRoot.AppendChild(xmlHead)
 
' Create the title tag, set it's text to "Database Table"
' and append it under the head element.
Dim xmlTitle As XmlElement = xmlDoc.CreateElement("title")
xmlTitle.AppendChild(xmlDoc.CreateTextNode("Database Table"))
xmlHead.AppendChild(xmlTitle)

Wow, that’s a lot of code. What’s going on there? First, let’s look at the XmlDocument class. This is important when we’re generating XML documents. It’s what we use to create new elements. However, even though it creates new elements, it doesn’t add them to the document. Thus, we need to use the AppendChild method of the appropriate element to add it to the document. As you can see above, we created a root element (html) and added that to the XML document (xmlDoc) first. Then we created a head element, and added that to the root element, not the xmlDoc. This was done in order to form a hierarchy, which is, in essence, what a XML (and by extension HTML) document is.

Here is what the resulting XML/XHTML document would look like so far:

<html>
  <head>
    <title>Database Table</title>
  </head>
</html>

So far so good, let’s finish it off. Here’s the rest of the code we’d need to make our simple HTML document:

' Create the body element and append it to the root.
Dim xmlBody As XmlElement = xmlDoc.CreateElement("body")
xmlRoot.AppendChild(xmlBody)
 
' Create the table and append it.
Dim xmlTable As XmlElement = xmlDoc.CreateElement("table")
xmlBody.AppendChild(xmlTable)
 
' Create the rows.
For Each row As DataRow In dataTable
  Dim xmlRow As XmlElement = xmlDoc.CreateElement("tr")
  xmlTable.AppendChild(xmlRow)
 
  ' Create the cells.
  For Each item As Object In row
    Dim content As String = ""
    If IsDBNull(item) = False Then content = CStr(item)
    Dim xmlCell As XmlElement = xmlDoc.createElement("td")
    xmlCell.AppendChild(xmlDoc.createTextNode(content))
    xmlRow.AppendChild(xmlCell)
  End For
End For
 
' Write the XML/HTML document.
Response.Write(xmlDoc.OuterXml)

And there you have it: a programmatic way to generate an HTML document. So why bother? Here’s a few reasons:

Safety. If you generate your HTML document by concatenating strings, there’s a chance you might forget to close a tag. If you generate the document programmatically, you can ensure that all your tags will always be closed.

Maintainability and readability. I’ve had to deal with code where the HTML is generated by concatenation. It’s confusing and frustrating. If you generate your HTML documents programmatically, it’s a lot easier for a future programmer to follow what’s going on (especially if you, y’know, document it).

Reusability and modifiability. If you create your HTML document as a flat string, it makes it really hard to modify and reuse elsewhere in your code. For example, if you wanted to add a tag in the middle of your HTML document using the string concatenation method, you will have to do a lot of painful string manipulations. With the programmatic approach, it’s as simple as just calling AppendChild on the appropriate XmlElement.

Using an XmlDocument to represent an XML document just makes sense. It’s less crude and more versatile.