convertire un .net Func <T> in un'espressione .net <Func <T>>

Passare da un lambda a un'espressione è facile usando una chiamata al metodo ...

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

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

Ma vorrei trasformare il Func in un'espressione, solo in rari casi ...

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());
}

La riga che non funziona mi dà l'errore in fase di compilazione Cannot implicitly convert type 'System.Func<T>' to 'System.Linq.Expressions.Expression<System.Func<T>>'. Un cast esplicito non risolve la situazione. C'è una struttura per fare questo che sto trascurando?

Ooh, non è affatto facile. Func<T>rappresenta un generico delegatee non un'espressione. Se esiste un modo per farlo (a causa delle ottimizzazioni e di altre cose fatte dal compilatore, alcuni dati potrebbero essere buttati via, quindi potrebbe essere impossibile recuperare l'espressione originale), sarebbe disassemblare l'IL al volo e inferire l'espressione (che non è affatto facile). Trattare le espressioni lambda come data ( Expression<Func<T>>) è una magia eseguita dal compilatore (fondamentalmente il compilatore costruisce un albero delle espressioni nel codice invece di compilarlo in IL).

Fatto correlato

Questo è il motivo per cui i linguaggi che spingono i lambda all'estremo (come Lisp) sono spesso più facili da implementare come interpreti . In quei linguaggi, codice e dati sono essenzialmente la stessa cosa (anche in fase di esecuzione ), ma il nostro chip non può capire quella forma di codice, quindi dobbiamo emulare una macchina del genere costruendovi sopra un interprete che la capisca (il scelta fatta dal Lisp come i linguaggi) o sacrificando la potenza (il codice non sarà più esattamente uguale ai dati) in una certa misura (la scelta fatta da C #). In C #, il compilatore offre l'illusione di trattare il codice come dati, consentendo l'interpretazione di lambda come code ( Func<T>) e data ( Expression<Func<T>>) in fase di compilazione .

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

Quello che probabilmente dovresti fare è cambiare il metodo. Prendi un'espressione>, compila ed esegui. Se fallisce, hai già l'espressione da esaminare.

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());
}

Ovviamente è necessario considerare le implicazioni sulle prestazioni di questo e determinare se è qualcosa che è davvero necessario fare.

Puoi andare dall'altra parte tramite il metodo .Compile (), tuttavia, non sono sicuro che sia utile per te:

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());
}

Se a volte hai bisogno di un'espressione e talvolta hai bisogno di un delegato, hai 2 opzioni:

• hanno metodi diversi (1 per ciascuno)
• accetta sempre la Expression<...>versione e basta .Compile().Invoke(...)se vuoi un delegato. Ovviamente questo ha un costo.

NJection.LambdaConverter è una libreria che converte i delegati in espressione

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 del team Cecil Mono sta facendo dei progressi per consentire questo

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

Modificare

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

Per

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