Having just glanced at the clock, now is the ideal time to post about an idea I had a little while ago – a book (or blog, or something) about C# (or maybe C# and Java) which I’d only write between midnight and one in the morning.
It would contain only those things which seemed like really good ideas at the time – but which might seem insane at other times. Most of these ideas are probably useless, but may contain a germ of interest. While I don’t always have those ideas between midnight and one, that’s the time of night when they seem most potent, and when I’d be most likely to be ready to write enthusiastically about them. The coding equivalent of “beer goggles” if you will.
A couple ideas I’ve had which would probably qualify:
Extension interfaces
If C# 3.0 is going to allow us to pretend to add methods to classes, which shouldn’t it allow us to pretend that classes implement interfaces they don’t? My original reason for wanting this is to get rid of some of the ugliness in the suggesting new XML APIs: there’s a method which takes an array of objects, even though only a handful of types are catered for. Unfortunately, those types don’t have an interface in common, so all the checking has to be done at runtime. If you could pretend that they all implement the same interface, just for the purposes of the API, you could declare the method as taking an array of the interface type. Of course, this is much less straightforward than converting what looks like an instance method call into a static method call…
Conditional returns
This came up when implementing Equals for several types in quick succession. All of them followed a very similar pattern, and there were similar things needed at the start of each implementation – simple checks for nullity, reference identity etc. It would be interesting to have a sort of “nullable return” for methods which had a non-nullable value type return type – I could write return? expression; where the expression was a nullable form of the return type, and it would only return if the expression was non-null. There are bits of this which appeal, and bits which seem horrible – but the main problem I have with it is that I suspect would rarely use it outside Equals implementations. (If this isn’t a clear enough description, I’m happy to write an example – just not right now.)
Jon Skeet's coding blog 
Extension interfaces sound like a good idea that should be simple to implement. So when the compiler sees an interface cast that is applied to a class which does not implement that interface, it would first check whether the class implements the properties & methods required by the interface, and if so, perform the cast "as if" the class implemented the interface — did I understand that correctly? That would be very useful, I think.
Conditional returns are a surprising suggestion for someone who thinks var might be hard to read. :p
I think you’re correct that it’s too rarely useful to warrant an extra keyword (or keyword modifier). What I really want is a way to auto-generate all the cruft that comes with Equals/operator== implementations… is one side null? The other side? Both sides? Yawn.
Same thing for comparison operators. Of course I want operator< to return true if CompareTo is negative, or if the left side null and the right side isn’t. Why do I have to write this over and over again?
Perhaps some attributes like [GenerateNullChecks] and [GenerateOperator] would be appropriate…
PS: Jon, your "Human Proof" appears broken. I have to retry two or three times before one of my entries is accepted, and I don’t think I’ve misread the characters — they appear very clearly.
LikeLike
Extension interfaces: The trouble is working out what the cast should do. It would have to wrap the type – you’d end up with two objects that way, one of the instance which implements the interface, and one which is the actual object itself. I suspect there are deep, deep problems there :(
Conditional returns: My problem with "var" is that it loses information for the reader. Conditional returns wouldn’t do that. They would, however, be yet another bit of language to learn, in a language which is getting very big already.
Human proof: yes, it’s broken. There’s not a lot I can do about it, unfortunately, other than to hope that the blog system is updated at some stage. In the meantime, please email me with comments you wish to have posted if you have trouble, and I’ll keep trying until it works! At least the previous values of the form are preserved…
LikeLike
Extension interfaces:
Are you proposing that the compiler would check if the object being passed as a parameter can pass as an instance of a class that implements that interface?
How would the generated code behave?
What guarantee would you have in your code that the parameters are of the type you want and not something mascarading as it?
LikeLike
Hi Jon,
I’ve just spotted your comments on extension interfaces. I recently posted some ideas on trying extension methods to interfaces to resolve versioning issues. It would help with extension interfaces too (but still wouldn’t solve the problem of having two objects instead of one…)
LikeLike