At Microsoft’s Lang.NET Symposium, where they also open-sourced the Common Compiler Infrastructure, their half-LLVM-half-Cecil libraries, Ted Neward speculates about an “Objective-C#”, or C# with messaging.
I wish someone who actually knew Objective-C had been involved. There were some real and some half-facts involved, and the real facts didn’t hold much sway. There was a constant dithering between a) the Objective-C branch of language philosophy, b) actual Objective-C features and c) badly misunderstood Objective-C features. So from someone who actually knows Objective-C…
Class methods and instance methods. A static method in C# is not a class method; you can’t stick one in an interface, you can’t override one. There’s not even a keyword to statically refer to the current/parent class the way
this/basedo for the current/parent instance. This is one of the most glaring ways in which the C# object model makes a mockery of its own claim to be object oriented.Protocols. They were badly maligned in that the required and optional methods were mentioned, but that the whole thing was made up to be duck typing. With duck typing, everything’s optional. A .NET-style interface with optional methods and the ability to reason at run time whether a method is implemented or not while being sure that another method is definitely implemented is enormously powerful. You have to create interface hierarchies and cast hither and fro to create something like this.
Categories, or external additions to classes. Extension methods take us most of the way there, but it is impossible to create extension methods for classes; something that’d be wonderful for enums.
Selectors. Of course confused with named parameters as every so often, which chills me slightly. If there was anywhere a room full of people where this mistake shouldn’t have been done, this was it. There are two things about selectors that make them so much more than even named parameter invocation in C# 4, which similar syntax helps towards readability: selectors are ordered and can thus repeat, and more importantly, a selector is the name of a message. Enough about functions as objects, this lets you reason about specific method signatures as an object, and I don’t just mean an arity and a type map, but a named segment with each parameter; two methods can take the same number and the same types of arguments and do completely different things with them, and with (C#) delegates you’d have to invent a word for each such action, including each permutation that takes slightly different arguments.
(Update: Vivek points out in the comments that selectors themselves don’t keep track of the type of their arguments, which is true. In every place where selectors are applied in a written-down interface (protocols, categories, object/class definition), though, they are by necessity defining a method (or message), which has types. The method name is more expressive and through that more reusable is what I’m driving at.)