6 posts from February 2008

I've heard a lot of people claim their illegal downloading of music is sort of like Robin Hood, stealing from the rich music companies and giving to the poor (themselves). Makes it sound almost noble.

The trouble is that there is too much good free music for this analogy to hold up. Which is why I like to compare it to stealing bottled water instead. Everyone knows bottled water is not really that much better than that which effectively comes out of your tap for free*. They make an insane profit by convincing everyone they need expensive, fancy bottled water, the greedy bastards. So let's fix this injustice by stealing the bottled water. Except then the retail outlet loses money. And you could just get the water from your tap.

It's the same, in my opinion, as illegally downloading music, except with the roles reversed (the makers unfairly lose money, not the distributors). If you really cared about the injustice you wouldn't steal the music, you would do more to support various movements such as Creative Commons which give artists much finer control over how their music is used and netlabels which as a culture tends to give more rights over to the artists.

I'm building up a catalogue of good sources for free music at the moment. I've got a few sites, but I want to be able to cover a wide range of music, and unfortunately a lot of good free music does tend to skew to the hip-pop/drum and base/instrumental side of things. I'm also working on some criteria by which to classify a record label as "fair", which obviously is more difficult than "the artist has chosen to put the music out for free" which is why I'm starting with free music.

* For this to work, think of the water bills as equating to your internet bills, though it doesn't really. But it fits better than Robin Hood. Besides, most people I know using the Robin Hood example have never paid their own water bills.

Quite often I end up doing something like this in my code:

Type returnType;
switch (function.ReturnType)
{
    case ReturnType.Boolean :
        returnType = typeof(bool);
        break;
    case ReturnType.State:
        returnType = stateEnum;
        break;
    case ReturnType.Tape:
        returnType = typeof(Tape);
        break;
}

This covers every value in the ReturnType enum, yet (for a very good reason that I forgot) the compiler isn't able to detect that, because of this, returnType will always be initialized after the switch statement. The way I used to get around this was by using:

...
case ReturnType.State:
    returnType = typeof(stateEnum);
    break;
default:
    returnType = typeof(Tape);
    break;

The problem with this is that it isn't obvious what the last "default" condition is. Then today I had a revelation (one I'm sure everyone else had a long time ago). It now looks like this:

Type returnType;
switch (function.ReturnType)
{
    case ReturnType.Boolean :
        returnType = typeof(bool);
        break;
    case ReturnType.State:
        returnType = stateEnum;
        break;
    case ReturnType.Tape:
        returnType = typeof(Tape);
        break;
    default:
        Debug.Assert(false, "Not implemented all the enums.");
        return;
}

Now not only is returnType seen to be initialized at every point it needs to be and every condition is clear, but we get a debug message if we add an item to the enum and forget to handle it. Okay, it's not as good as a compile time message but it's the next best thing.

I've tried in the past to work out what a valid name looks like in CIL so I can implement it in my Turing.Net compiler and never got very far. Today I decided to just knuckle down and plow through the ECMA Specification. It's actually rather interesting, and I eventually came across section 8.5.1 Valid names*:

CLS Rule 4: Assemblies shall follow Annex 7 of Technical Report 15 of the Unicode Standard 3.0 governing
the set of characters permitted to start and be included in identifiers, available on-line at
http://www.unicode.org/unicode/reports/tr15/tr15-18.html. Identifiers shall be in the canonical format defined
by Unicode Normalization Form C. For CLS purposes, two identifiers are the same if their lowercase mappings
(as specified by the Unicode locale-insensitive, one-to-one lowercase mappings) are the same. That is, for two
identifiers to be considered different under the CLS they shall differ in more than simply their case. However,
in order to override an inherited definition the CLI requires the precise encoding of the original declaration be
used.

When you look at the standard and normalized forms it's a little scary, but it turns out the framework makes it all very easy. First, normalization:

s = s.Normalize();

Told you it was easy. It defaults to Form C, but you can specify other forms too. As for checking whether a string conforms to the identifier we can use the very simple regular expression:

start = (\p{Lu}|\p{Ll}|\p{Lt}|\p{Lm}|\p{Lo}|\p{Nl})
extend = (\p{Mn}|\p{Mc}|\p{Nd}|\p{Pc}|\p{Cf})
start(start|extend)*

The \p basically mean "match anything of this Unicode class" and if you look at the specification given on the Unicode website it matches up very nicely.

* It turns out there is a formal Common Language Specification which it comes under, as opposed to the watered down one I'd previously only been able to find.

I've been reading through the Ecma specification for the CLI in order to find out some things for Turing.Net and came across an interesting little fact, represented by the following code:

Console.WriteLine(float.NaN.Equals(float.NaN)); // True
Console.WriteLine(float.NaN == float.NaN); // False

This is because, under the contract for type value, equality identity implies equality. However, "two floating point NaNs are defined by IEC 60559:1989 to always compare as unequal."* Well I thought it was interesting.

* http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-335.pdf p21 ac. Feb 2008

Previously I've posted about a technique to create conditional methods on generics, that is methods on a generic class that only appear if the generic type impliments some interface. Perhaps not the best solution to the problem, but an interesting one.

Last night I had a brainwave - perhaps you can create a much cleaner conditional method with extension methods. Extension methods were added to C# 3.0 as a syntactic sugar for turning:

DateTime.Now.Funkify(10);

into

ICR.ExtensionClasses.Funkify(DateTime.Now, 10);

such that you write the first line, but the compiler treats it as the second.

Here's how you would use extension methods to create a conditional method on a generic class:

public class MyClass<T>
{
    public T Item1 { get; set; }
    public T Item2 { get; set; }
}

public static class MyClassExtensions
{
    public static void MyMethod(this MyClass<IComparable> myClass)
    {
        return myClass.Item1.CompareTo(myClass.Item2);
    }
}

Then you would use it like so:

MyClass<IComparable> comparableClass = new MyClass<ComparableType>();
int i = comparableClass.MyMethod();

There are a few limitations on how this works. Firstly the conditional method can only operate on the public members of the class, as it's really a static call from outside the class passing the instance in as a parameter. Secondly, when you are using it you can only use it if you cast the generic type to the interface type. This is perhaps a bit of a bonus - it makes the code arguably easier to understand (it makes it seem less arbitrary what classes have the method and what don't).

My favourite feature of Visual Studio 2008, I've decided, is automatic properties. I say they're a feature of VS2008 because you can use them in code that targets .NET 2.0 - after all the compiler just expands them out like a code snippet. I've been forced to work with VS2005 recently (for the XNA Studio) and I really miss them, my code is begining to look like a mess with the expanded properties everywhere.

If you've not come across automatic properties before, they take this:

private string name;
/// <summary>
/// The name of the employee.
/// </summary>
public string Name
{
  get { return name; }
  set { name = value; }
}

and turn it into:

/// <summary>
/// The name of the employee.
/// </summary>
public string Name { get; set; }

A lot cleaner and more readable! The compiler generates the backing variable for you, which is great because most of the time properties are just simple accessors for fields. Of course, if you need to do more exciting stuff like validation you can still use the full property.

Even if you know about automatic properties, you may not have come across this very useful trick:

/// <summary>
/// The amount of stock left.
/// </summary>
public int StockCount { get; private set; }

If you've got an automatic backing variable, there is no way to assign a value to it, so you can't create read-only variables by ommiting the set accessor. The solution to this is to make the set accessor private such that the property can only be set from inside the containing class. What I really like about this is that it means, with a proper naming convention, it's now more obvious when you're modifying a property rather than a field. But then I guess it's not less obvious when you're modifying a read-only property. Swings and roundabouts.

This is all a very long winded way of saying "I miss you automatic properties, but I'll be home soon, I promise!"