Cook Computing

The Internal Coding Guidelines posted by Brad Abrams are very similar to the style I prefer. Perhaps the main difference is that I use an underscore prefix for member variables, although I've never been completely happy with this. It has the advantage of distinguishing members from locals and parameters but it does have a slighly unpleasant whiff of kludginess about it. On the other hand using the this.member convention adds to verbosity (but does bring intellisense into play which can save some typing).

Yesterday I mentioned I'd like to experiment with Longhorn by installing it onto an external USB drive. I'm not so sure now whether that will be possible. I came across a post by Raymond Chen Why can't I install Windows on my USB drive? :

A collection of limitations (both hardware and software) currently prevent Windows from booting and running off a USB drive. Some of them are described in this whitepaper from WinHEC 2003. Another reason not mentioned in this paper is that during any hot-plug operation, the USB bus is completely reinitialized. Windows really doesn't like it when it loses access to its boot device. Imagine, you plug in a USB camera, the USB bus reinitializes, Windows loses access to the boot drive, and *oops* the kernel needs to page in some data and it can't.

However there is a paper on the Windows Hardware and Driver Central site - Recommendations for Booting Windows from USB Storage Devices - which suggests that installing on a USB drive may be supported in Longhorn.

I started using my new work dev machine this week. The key features are 3G of memory and 2x160G SATA drives arranged as RAID0, so it performs reasonably well. Complete with a fast processor something like this should be considered as a standard developer configuration these days. The old machine only had 512M of memory which is nowhere near enough for development purposes when you may want to run several instances of Visual Studio, the application you're working on, in my case is a large server application, Office apps, browser instances, Virtual PC, and an aggregator.

The graphics card is a Radeon X800 XT which hopefully should be sufficient for the graphics requirements of Longhorn. When the beta arrives sometime this year (?) I'd like to experiment with installing it onto an external USB2 drive so that I can boot off that when I want to play with Longhorn, yet leave my development environment untouched on the drives in the machine.

I chose a 20" LCD monitor which looks very good at 1600x1200. I experimented with dual 19" monitors at 1280x1024 but found that my preferred Visual Studio layout on one of the monitors (Output/Find Results/etc on the left, 80 columns of code in the middle, and solution explorer on the right) was too cramped, and I didn't want to have to keep looking at the other monitor when working on code. Walking round the office I did cringe a bit to see people working with Visual Studio maximised on a 1600x1200 screen with code extending across the full width of the screen. I don't particularly like working with lines of code stretching to 200 odd characters and the excessive levels of indentation that become too much of a temptation. What happens when developers move to 30" screens?

The only aspect of development which still drags is ClearCase. This is horrendously slow over a broadband/VPN connection and I can't begin to understand why such simple tasks such as checking out a single file take so long. Maybe the original developers were averse to premature optimization.

Brad Wilson's post The Love Affair is Over prompted me to investigate .NET generics (long overdue I know). The gist of Brad's complaint seems to be that the following does not compile

class TestClass<T> 
{
    public void Foo(T t)
    {
        t.Bar();
    }
}

This is because the compiler cannot determine that type T will contain a method called Bar with the required signature. The C# designers decided that the compiler should not make an inference about the "latent type" of Type T. All the compiler knows from this code is that type T is of type Object.and so, for example, this compiles successfully:

class TestClass<T> 
{
    public void Foo(T t)
    {
        t.ToString();
    }
}

To compile the first class definition above it is necessary to provide a constraint on Type T, for example:

interface IBar
{
    void Bar();
}

class TestClass<T> where T : IBar
{
    public void Foo(T t)
    {
        t.Bar();
    }
}

A while ago Ian Griffiths wrote an interesting post on this topic: Generics, Latent Types, and Type Safety in which he illustrates that IL code using the concept of "latent typing" can be compiled, though it fails at runtime, which suggests that at some point in the future we might be able to write code along the lines of this:

class TestClass<T> where T : any
{
    public void Foo(T t)
    {
        t.Bar();
    }
}

Ian does however point out that the current implementation of generics prevents problems with versioning which could only be detected at runtime.

So the purpose of .NET generics in its current implementation is to make it possible to implement type-safe containers, for example, collections, and to avoid the need for downcasting in certain situations. For example, when using the XmlRpcProxyGen class in XML-RPC.NET to create a proxy, a cast is required, for example:

IFoo fooProxy = (IFoo)XmlRpcProxyGen.Create(typeof(IFoo));

With generics it will be possible to remove the need for the cast:

IFoo fooProxy = XmlRpcProxyGen.Create<IFoo>();

For a comprehensive description of how to use generics I recommend Juval Lowy's An Introduction to C# Generics.