conversion d'un .net Func <T> en une expression .net <Func <T>>

Passer d'un lambda à une expression est facile en utilisant un appel de méthode ...

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

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

Mais je voudrais transformer le Func en une expression, seulement dans de rares cas ...

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 ligne qui ne fonctionne pas me donne l'erreur de compilation Cannot implicitly convert type 'System.Func<T>' to 'System.Linq.Expressions.Expression<System.Func<T>>'. Un casting explicite ne résout pas la situation. Y a-t-il une possibilité de faire cela que je néglige?

Ooh, ce n'est pas du tout facile. Func<T>représente un générique delegateet non une expression. S'il y a un moyen de le faire (en raison des optimisations et d'autres choses effectuées par le compilateur, certaines données peuvent être jetées, il peut donc être impossible de récupérer l'expression d'origine), ce serait désassembler l'IL à la volée et inférer l'expression (ce qui n'est en aucun cas facile). Traiter les expressions lambda comme des données ( Expression<Func<T>>) est une magie faite par le compilateur (en gros, le compilateur construit un arbre d'expression dans le code au lieu de le compiler en IL).

Fait connexe

C'est pourquoi les langages qui poussent les lambdas à l'extrême (comme Lisp) sont souvent plus faciles à implémenter en tant qu'interprètes . Dans ces langages, le code et les données sont essentiellement la même chose (même au moment de l'exécution ), mais notre puce ne peut pas comprendre cette forme de code, nous devons donc émuler une telle machine en construisant au-dessus un interpréteur qui la comprend (le choix fait par Lisp comme les langages) ou sacrifier la puissance (le code ne sera plus exactement égal aux données) dans une certaine mesure (le choix fait par C #). En C #, le compilateur donne l'illusion de traiter le code comme des données en permettant aux lambdas d'être interprétées comme code ( Func<T>) et data ( Expression<Func<T>>) au moment de la compilation .

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

Ce que vous devriez probablement faire, c'est changer la méthode. Prenez une expression>, compilez et exécutez. En cas d'échec, vous avez déjà l'Expression à examiner.

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

De toute évidence, vous devez tenir compte de ses implications en termes de performances et déterminer si c'est quelque chose que vous devez vraiment faire.

Vous pouvez cependant aller dans l'autre sens via la méthode .Compile () - vous ne savez pas si cela vous est utile:

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

Si vous avez parfois besoin d'une expression et parfois besoin d'un délégué, vous avez 2 options:

• ont des méthodes différentes (1 pour chacune)
• acceptez toujours la Expression<...>version, et uniquement .Compile().Invoke(...)si vous voulez un délégué. Évidemment, cela a coûté.

NJection.LambdaConverter est une bibliothèque qui convertit les délégués en expression

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 de l'équipe Cecil Mono fait des progrès pour permettre cela

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

Changement

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

À

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