Legacy API requires to pass callback name as string. Can I improve that API via an extension method?

I'm faced with a legacy API that doesn't use .NET events, but rather requires me to do this:

// (first arg is System.Object, second arg is string, myFoo is of type Foo)
myFoo.AddCallback(this, "DoSomething(int)");

This API requires that DoSomething be an instance method on this, and that it take an int.

Is there a way I can use force this API to be usable in a typesafe way?

More precisely: I want to write an extension method for Foo, which allows me to call AddCallback with a .NET delegate, rather than a receiver-signature pair. I'm imagining something like this:

// extension method definition
public static void AddCallback(this Foo foo, Action action)
{
    foo.AddCallback(
        FigureOutReceiverOf(action),    // ?
        FigureOutSignatureOf(action));  // ?
}

public static void AddCallback<T>(this Foo foo, Action<T> action)
{ ... } // and so on, for up to, say, 10 type-arguments

// usage:
myFoo.AddCallback(DoSomething)
// or even a lambda:
myFoo.AddCallback((i) => Console.WriteLine(i));

If it's possible to do this via an extension method hack, it would make my l开发者_StackOverflowife better. Also I'm simply interested if it's possible given C#'s capabilities.

By the way, the legacy API is called qt4dotnet.

---

Using a lambda would be tricky - it will end up being a method in a different class, if it captures local variables. You could detect that, of course, but it wouldn't be compile-time safe.

Likewise the signature part is interesting, in that if it's definitely an Action, the delegate has no parameters. You can't just make the parameter Delegate, or method group conversions won't work... although you could still call

myFoo.AddCallBack(new Action<int>(MyMethodName));

An alternative is to produce a bunch of overloads:

public static void AddCallback(this Foo foo, Action action)

public static void AddCallback<T>(this Foo foo, Action<T> action)

public static void AddCallback<T1, T2>(this Foo foo, Action<T1, T2> action)

It wouldn't be elegant, but you'd probably only need a few for practical reasons. If any methods returned values, you'd need similar ones for Func.

There's the additional potential problem of passing a delegate with multiple actions... again, you could check this at compile-time. Finally, you might want to check that the Target of the delegate is the same as the foo parameter.

With these problems out of the way, working out the signature is relatively straightforward. You use the Delegate.Method property, and from that you can get the name and parameter types. If the library requires "int" rather than "System.Int32" etc then you'll need a bit of faffing around that, but it shouldn't be too bad. (It does sound like a pretty odd API though.)