IanG on Tap

This entry's subject is not a new idea, and one which most .NET developers are probably already aware of, but I happened to come across it in three different contexts in quick succession this week so I thought I'd write about it. And if you're already quite familiar with the issue, skip to the last paragraph for a brainteaser that might still be new to you. The first place I came across this idea recently was in a paper on Xen, written by two people from Microsoft Research and one person from the Computer Labs at the University of Cambridge - they refer to the distinction between edge-labelled and node-labelled graphs. Meanwhile, Stan Lippman discussed the nature of .NET object references in a blog entry on copy constructors in managed C++, calling out the "phase-shift" that occurs between the initialization of a reference and its subsequent use. The language is all rather different, but it's the same basic idea. And the third context was a private email which I obviously won't link to here.

The issue here can best be summed up by asking this question: what exactly is 'obj1' in the following snippet?

string obj1 = "Hello, world";

I regularly teach teach various courses on .NET. In my experience, most people learning C# will say, quite reasonably, that obj1 is the string "Hello, world". However, this isn't quite right. This is confusing the reference with the referent. obj1 isn't actually the string "Hello, world", it's a variable holding a reference to that string. (To borrow a phrase a sociologist once told me, this distinction could be described as "the distance between the signifier and the signified." If you like that kind of language.) This distinction can easily be highlighted by extending the example:

string obj1 = "Hello, world";
obj1 = "Hello, sailor!";

At this point it becomes clear that the first answer to the question is incorrect - obj1 is referring to different strings after each line, even though it is obviously the same variable in each case. (If you are a fan of functional languages with referential integrity, now would be an appropriate moment to sneer. Thank you.) This example illustrates the fact that the variable is not the same thing as the string. And at this stage you might be thinking that this is pretty basic and straightforward stuff. And I'd be inclined to agree, except for the fact that I'm sure I'm not the only one who hears people talk about, say, "the foo object" in examples like this:

MyClass foo = new MyClass();
foo.Bar();

Now I'd like to believe that when people say "the foo object", they're using this as a convenient shorthand for "the object that foo refers to". Except that I have learnt from experience that a surprising number of experienced professional developers don't in fact make this distinction. The authors of the Xen paper have evidently noticed the same thing. As they say, "at best many people seem unaware of this difference, and at worst confuse the two." (They couch it in terms of edges and nodes, but that's just graph-theory-speak. References are edges, and objects are nodes, in this context..)

Of course it's not helped by the fact that in some circumstances, the distinction is unimportant. For example, consider a Windows Forms application created in Visual Studio .NET. The Control class, which is the base class of almost all visual components in a Windows Forms application, has a Name property. So in this particular case it is actually meaningful to use phrases like "the txtInputCurrency object" because there really can be an object which has that name. (In general such statements have no clear meaning, because the CLR doesn't require objects to have names.) Furthermore, the Visual Studio .NET Forms Designer creates variables for every control that it creates, and these variables have the same name as the controls to which they refer. So in this particular case, the name of the variable is usually the same as the name of the corresponding object. This is perfectly reasonable of course, but it does tend to prolong the confusion for those not aware of the distinction.

Once you're aware of the distinction, it brings up a new conundrum. How exactly do variables fit into .NET's type system? In that very first example, there are two things: a string and a variable referring to the string. The type of the string itself it obvious: System.String. But what exactly is the variable, according to the .NET type system? (I apologise for not having written a comments feature. Feel free to email me if you'd like to share your answer with someone. I may post the best answers in a followup blog...)