See:
http://blogs.msdn.com/charlie/archive/2008/01/25/future-focus.aspx

[*]I dislike that marketecture phrase…wasn’t adding categories, or protocols, or language-level exceptions, a reversion of Objective-C?

Also, I really think categories/extensions in the System namespace are *good*, especially if you get link-time conflict checking.

We frequently define default implementations of functionality on NSObject and then specialize where necessary. I really dislike code like this:

if ([object respondsToSelector:@selector(foo)])
[object foo];
else {
… default logic …
}

It’s slower, more verbose, more fragile and worst, ugly! Instead of this, I’ll put the default logic on NSObject, skip the respondsToSelector: and just call -foo straight up.

If someone has a better pattern, I’m open to suggestions, but this has served us well and with link time conflict checking it’d be even better (actually, I have a little command line tool that uses our OmniMachO framework to check for method override conflicts at runtime, but that requires me to actually invoke it…

What happens with dynamically loaded code?

The extension method is definitely getting resolved at compile time, it’s not going to make a difference with dynamically loading code adding new extension methods (Unless maybe if you have the same method extension in two different assemblies with the same namespace like System in static classes with the same names , which would cause a runtime error on load because of the class with the same name and namespace)

OK — more basic question that demonstrates my ignorance — what dynamic loading features does C# even support?

Libraries, modules, and you can emit new classes programatically too.

Hell, what level of support does C# have for dynamic resolution and/or binding of methods?

Most of the time you are not dynamically resolving methods, there is some runtime resolving for methods obviously for virtual methods and protocols (err… interfaces) only what you would need for polymorphism. Also while it’s not a language feature, .net does have the ability to dynamically query methods via the reflection api and then invoke them, it’s big and ugly, but it does allow one to write classes that use dynamic bindings. The api query can be much more explicit than cocoa’s, but of course there’s a lot more meta data in c# than objective-c to query by too.

C# is statically and strongly typed, but they do make it possible to do things you expect in dynamic languages, they can even do distributed objects with proxies, the only catch is that you have to have a protocol (err…interface) for that object, but you just feed it to an api and it’s emits a proxy class that inherits the protocol on the fly and it will talk on the other end to an object that invokes methods dynamically by reflection off your remote object.

I agree that this can cause problems (obviously) but the power to fix bugs in frameworks provided by someone else (cough apple cough) should not be trivialized. The amount time time I have saved because I could fix a bug by using categories is significantly greater than the time I have spent hunting down category related bugs.

That said, it would be nice if you had to explicitly say when you wanted to override an existing method. You could prefix the method with something like override_stupid_borken_method_so_things_work_like_they_should, or even just override. Without the keyword it would go boom, or simply not load the category.

C# has an override keyword, unfortunately the original method has to be declared virtual which is not the default and therefore doesn’t get used much.

On a different note I find it sad that it took LINQ to get MS to see the use of categories, and then only begrudgingly.

-Mont

Using your example:


object obj = new object();
obj.MagicDoStuff();


gets compiled to


object obj = new object();
MagicDoStuff(obj);


It’s syntactic sugar which I guess was put in mainly to support LINQ. Without it, the syntax for LINQ would be horrible. (Given that all the System.Query methods couldn’t be added to the IEnumerable<T> interface without some serious breakage…)