konwertowanie .net Func <T> na .net Expression <Func <T>>

Przejście od lambdy do wyrażenia jest łatwe przy użyciu wywołania metody ...

public void GimmeExpression(Expression<Func<T>> expression)
{
    ((MemberExpression)expression.Body).Member.Name; // "DoStuff"
}

public void SomewhereElse()
{
    GimmeExpression(() => thing.DoStuff());
}

Ale chciałbym zmienić Func w wyrażenie, tylko w rzadkich przypadkach ...

public void ContainTheDanger(Func<T> dangerousCall)
{
    try 
    {
        dangerousCall();
    }
    catch (Exception e)
    {
        // This next line does not work...
        Expression<Func<T>> DangerousExpression = dangerousCall;
        var nameOfDanger = 
            ((MemberExpression)dangerousCall.Body).Member.Name;
        throw new DangerContainer(
            "Danger manifested while " + nameOfDanger, e);
    }
}

public void SomewhereElse()
{
    ContainTheDanger(() => thing.CrossTheStreams());
}

Linia, która nie działa, wyświetla błąd w czasie kompilacji Cannot implicitly convert type 'System.Func<T>' to 'System.Linq.Expressions.Expression<System.Func<T>>'. Jawna obsada nie rozwiązuje sytuacji. Czy istnieje możliwość zrobienia tego, czego nie zauważam?

Ooh, to wcale nie jest łatwe. Func<T>reprezentuje rodzaj, delegatea nie wyrażenie. Jeśli można to zrobić w jakikolwiek sposób (z powodu optymalizacji i innych rzeczy wykonanych przez kompilator, niektóre dane mogą zostać wyrzucone, więc odzyskanie oryginalnego wyrażenia może być niemożliwe), byłby to demontaż IL w locie i wywnioskować wyrażenie (co wcale nie jest łatwe). Traktowanie wyrażeń lambda jako danych ( Expression<Func<T>>) jest magią wykonywaną przez kompilator (w zasadzie kompilator buduje drzewo wyrażeń w kodzie zamiast kompilować je do IL).

Powiązany fakt

Dlatego języki, które wypychają lambdy do skrajności (takie jak Lisp), są często łatwiejsze do zaimplementowania jako interpretery . W tych językach kod i dane są zasadniczo tym samym (nawet w czasie wykonywania ), ale nasz chip nie może zrozumieć tej formy kodu, więc musimy emulować taką maszynę, budując na niej interpreter, który ją rozumie ( wybór dokonany przez Lisp podobnie jak języki) lub poświęcenie mocy (kod nie będzie już dokładnie równy danym) do pewnego stopnia (wybór dokonany przez C #). W języku C # kompilator daje złudzenie traktowania kodu jako danych, umożliwiając interpretowanie wyrażeń lambda jako code ( Func<T>) i data ( Expression<Func<T>>) w czasie kompilacji .

    private static Expression<Func<T, bool>> FuncToExpression<T>(Func<T, bool> f)  
    {  
        return x => f(x);  
    } 

To, co prawdopodobnie powinieneś zrobić, to odwrócić tę metodę. Weź Expression>, skompiluj i uruchom. Jeśli to się nie powiedzie, masz już wyrażenie do sprawdzenia.

public void ContainTheDanger(Expression<Func<T>> dangerousCall)
{
    try 
    {
        dangerousCall().Compile().Invoke();;
    }
    catch (Exception e)
    {
        // This next line does not work...
        var nameOfDanger = 
            ((MemberExpression)dangerousCall.Body).Member.Name;
        throw new DangerContainer(
            "Danger manifested while " + nameOfDanger, e);
    }
}

public void SomewhereElse()
{
    ContainTheDanger(() => thing.CrossTheStreams());
}

Oczywiście musisz wziąć pod uwagę wpływ tego na wydajność i określić, czy jest to coś, co naprawdę musisz zrobić.

Możesz jednak przejść w drugą stronę za pomocą metody .Compile () - nie jestem pewien, czy jest to przydatne:

public void ContainTheDanger<T>(Expression<Func<T>> dangerousCall)
{
    try
    {
        var expr = dangerousCall.Compile();
        expr.Invoke();
    }
    catch (Exception e)
    {
        Expression<Func<T>> DangerousExpression = dangerousCall;
        var nameOfDanger = ((MethodCallExpression)dangerousCall.Body).Method.Name;
        throw new DangerContainer("Danger manifested while " + nameOfDanger, e);
    }
}

public void SomewhereElse()
{
    var thing = new Thing();
    ContainTheDanger(() => thing.CrossTheStreams());
}

Jeśli czasami potrzebujesz wyrażenia, a czasami potrzebujesz pełnomocnika, masz dwie opcje:

• mają różne metody (po 1 dla każdego)
• zawsze akceptuj Expression<...>wersję i po prostu .Compile().Invoke(...)ją, jeśli chcesz delegata. Oczywiście to kosztuje.

NJection.LambdaConverter to biblioteka konwertująca delegatów na wyrażenie

public class Program
{
    private static void Main(string[] args) {
       var lambda = Lambda.TransformMethodTo<Func<string, int>>()
                          .From(() => Parse)
                          .ToLambda();            
    }   

    public static int Parse(string value) {
       return int.Parse(value)
    } 
}

 Expression<Func<T>> ToExpression<T>(Func<T> call)
        {
            MethodCallExpression methodCall = call.Target == null
                ? Expression.Call(call.Method)
                : Expression.Call(Expression.Constant(call.Target), call.Method);

            return Expression.Lambda<Func<T>>(methodCall);
        }

JB Evain z zespołu Cecil Mono robi pewne postępy, aby to umożliwić

http://evain.net/blog/articles/2009/04/22/converting-delegates-to-expression-trees

Zmiana

// This next line does not work...
Expression<Func<T>> DangerousExpression = dangerousCall;

Do

// This next line works!
Expression<Func<T>> DangerousExpression = () => dangerousCall();