Symbols, Part 2

I've previously written about how useful it would be to have compiler-checked symbols in C#. It allows you to identify methods, properties etc without having to use uncheckable (and un-refactorable) string literals. Insteads, you can use the method or property name and have it checked by the compiler (and refactored by your refactoring tool.)

I have some good news and some bad news:

• The good news: you can simulate named symbols for methods right now.
• The bad news: the technique doesn't work for properties (which is probably where you want it most).

Anyway, here's now to get a "named symbol" effect for methods. It relies on delegate inference to let you to use a method name and have the system automatically create a delegate. (Inspecting the delegate then gives the method info, when you need it.)

// Declare a delegate for a parameterless method 
// which returns void
public delegate void SimpleDelegate();

// This is the method to which you want to pass other
// methods. Its param is typed as SimpleDelegate
// Return type can be void or whatever you want.  
// I've used bool just for the sake of the example 
// below 
protected bool DoStuffWithMethod(SimpleDelegate d)
{
// here d.Method identifies the method
...
}
// Example of use:

// This is the method we want to refer to
public void Foo()
{ ... }

// here o.Foo is the compiler-checked "symbol"
MyObject o = new MyObject();
Assert.IsTrue(DoStuffWithMethod(o.Foo));

It would be great to have something similar for properties. Perhaps delegate inference could be extended so that if you use a property name instead of a method name, then the inferred delegate will point to the property's "getter" method.

P.S. as others have already pointed out, another solution for properties is to use LINQ-based syntax. Personally, I'd like something cleaner. I don't like the idea of writing "o => o.Foo" every time I want to say o.Foo (although I can't argue with the fact that it does work :-)

Finally, as noted here, a solution which worked in atttributes would be great (which is admitedly not the case for any of the solutions mentioned in this post).

Also see followup here.