Here's something I'd like to see possible in code. I presented it to the C# design team (well, actually, my suggestion was a bit more limited in scope), but they weren't particularly interested because it goes against a couple of the language design tenets.
I want a way to call methods on a null reference. Not just any method, but just special methods. In fact, these special methods would actually just be static methods that you access through unusual syntax.
The .NET Framework string class has a nice static method called IsNullOrEmpty. With it, you can make your code a little less tedious:
if (username == null || username.Length == 0) return;
if (string.IsNullOrEmpty(username)) return;
But, I really hate calling static methods and then passing in an instance of that same class. That's just silly. You're still doing something with username; the only difference in the paradigm is that username might not actually refer to a string. With what I'm calling a "ghost function" (a name I spent about thirty seconds coming up with), it becomes much cleaner:
if (username.IsNullOrEmpty()) return;
You wouldn't want that behavior on most methods; usually, you'd still want to throw if you call a method on null. Anyway, with my new imaginary syntax, not only does the code above become clearer, the actual definition of IsNullOrEmpty becomes slightly clearer too:
public static IsNullOrEmpty(string instance)
return instance == null || instance.Length == 0;
public ghost IsNullOrEmpty()
return this == null || Length == 0;
(Note that in the ghost method, you can use the "this" keyword and instance variables, even though it's technically a static method and not an instance method; it's just syntactic pleasantry.)
In the end, using a ghost method versus a regular static method would have identical results; in fact, for languages that didn't support ghosts, you could make them equivalent in the compiled IL. But, I think that the object.action() syntax is much more pleasant than the class.action(object) syntax. The language design team's response is that this sort of thing takes away from the clarity of the code, but I think it's just the opposite. (My original suggestion only dealt with properties, not regular methods.)