Chris Nokleberg's Fizzy Weblog
I'm not going to expound too much on the usefulness of delegates. I'm sure C# users like them, and any programmer with experience with functional language where functions are first-class objects, or even in C where you can pass function pointers around, should find them obviously useful. That's essentially what they are, function pointers shoehorned into a statically-typed OOP environment.
But C# wasn't the first OOP language to try this. I know of at least one other... J++! Apparently, the addition of delegates to the Java language was a major component of the embrace and extend actions by Microsoft that got everyone riled up. I understand the political issues, but I kind of wish that in this case Sun would have swallowed its pride and just given delegates to everyone.
For some fun reading on this subject, check out the propaganda from both sides:
I hate to say it, but I do find Microsoft's paper more convincing. The thing about Sun's argument that makes me laugh/cry is they're basically saying the only way to implement delegates is using reflection, and reflection is too slow and hard to use!
Well, Sun is (still) right about reflection, but there is a better way—BCEL! CGLIB has two classes, MethodDelegate and MulticastDelegate, that implement semantics very close to their C# cousins. They are slower to create, but run with very little overhead. Right now the documentation is just copied from the Avalon project; they use a Dynamic Proxy-based version similar to the one in the article, but may switch to CGLIB eventually. Unfortunately, because of this dispute it's probably true that we will never see delegate support built into Java, so this may be as close as we can get to the real thing.