2006-12-12

Things that annoy me about C#

Generally I really like C#, but there are a few things I don't like so here I am to have a bit of a moan about them.

01) I cannot specify constructor order!

When I add a constructor to a new class I cannot determine when I want the base class's constructor to be called, it is always called before any of the code in my new constructor. This means that if my base constructor calls a virtual method, and I override that method in my new class, I cannot always initialise any members the method might use.

public class BaseClass
{
public BaseClass()
{
Initialize();
}

protected abstract void Initialize();
}

public ChildClass : BaseClass
{
private readonly object SomeReference;

public ChildClass(object someReference)
: base()
{
this.SomeReference = someReference;
}

protected override Initialize()
{
SomeReference.ToString(); //Oops, it's null!
}
}


Why must I always call the inherited constructor first? I was pretty annoyed about it so I wrote to Anders H. It was nice that he wrote back, but "went off on one" about why he didn't want to implement named constructors (as per Delphi) and in the process completely neglected to answer the question.

The thing is, this is only a C# limitation. The .NET framework itself allows you to call a base constructor at any point you like!


02) No virtual class methods

I can't recall how many times I was temporarily banned from the C# channel on IRC (EFNET) because of arguing about this one. I think virtual class methods can be useful.

Now I must admit that since moving over to C# and not being able to use them I have found that most of the things I was using them for were probably wrong, for example using them to construct object instances when really I should have been using a factory pattern. However, sometimes they save so much coding that they are just useful!

I currently want to know if an instance of a subclass of Signal can be sent to an instance of ISignalTarget.GetSignalPermission() but I want to know this before creating an instance of the Signal subclass. I could do this by reflecting over the static methods of the class for a method with a certain signature but lets face it, the code isn't going to be strongly checked at compile time (accidentally typing the "GetSignalPermission" parameter incorrectly) and it is going to be the fastest code in the world either when I have to repeatedly check for compatibility between a list of ISignalTarget and a list of all possible signals!

At the moment I am having to write a factory class for every signal class. This means I am having to probably 10 times more work than I would if I had virtual class methods.


03) No strong type declarations!

Sometimes I just want to be able to say that I want a Type passed as a parameter, but this Type must be a subclass of Button or Control or something. I end up having to check the parameter at runtime, but I want to ensure the parameter is correct at compile time!

In Delphi I can do this

ControlClass = class of Control;

and then everywhere I refer to a ControlClass in parameters / variables etc it is automatically constrained "where xxxx : Control".


04) Array accessors on properties.

Why oh why can't I implement code like this without having to write a custom list class...

if (!Supplier.CatalogueItems["123ABC"].Discontinued)

I just want to be able to add an array property to Supplier, something like this

public CatalogueItem CatalogueItems
{
get[string catalogueNumber]
{
return SomeHashTable[catalogueNumber];
}
}



I think that's about it for now :-)

No comments: