C#: operatore implicita e Metodi di estensione

Question

Sto cercando di creare una classe PredicateBuilder<T> che avvolge un Expression<Func<T, bool>> e fornisce alcuni metodi per costruire facilmente fino un'espressione con vari And e Or metodi. Ho pensato che sarebbe stato bello poter usare direttamente questo PredicateBuilder<T> come Expression<Func<T, bool>>, e ho pensato che si potesse fare con un metodo implicit operator.

ridotta versione della classe si presenta così:

class PredicateBuilder<T> 
{ 
    public Expression<Func<T, bool>> Predicate { get; protected set; } 

    public PredicateBuilder(bool initialPredicate) 
    { 
     Predicate = initialPredicate 
      ? (Expression<Func<T, bool>>) (x => true) 
      : x => false; 
    } 

    public static implicit operator Expression<Func<T, bool>>(
     PredicateBuilder<T> expressionBuilder) 
    { 
     return expressionBuilder.Predicate; 
    } 
} 

Poi, proprio come un test, ho questo metodo di estensione in una classe statica:

public static void PrintExpression<T>(this Expression<Func<T, bool>> expression) 
{ 
    Console.WriteLine(expression); 
} 

Nella mia testa, ho dovrebbe quindi essere in grado di fare questi:

var p = new PredicateBuilder<int>(true); 

p.PrintExpression(); 
PredicateExtensions.PrintExpression(p); 

Tuttavia nessuno di loro funziona. Per il primo, il metodo di estensione non è stato trovato. E per il secondo, si dice che

Il tipo di argomenti per il metodo 'ExtravagantExpressions.PredicateHelper.PrintExpression (System.Linq.Expressions.Expression>)' non possono essere dedotti dal loro utilizzo. Prova a specificare esplicitamente gli argomenti del tipo.

Così ho provato la seguente, che ha funzionato:

PredicateExtensions.PrintExpression<int>(p); 

Inoltre, questo funziona, naturalmente:

((Expression<Func<int, bool>>) p).PrintExpression(); 

Ma sì ... perché non gli altri lavorano? Ho frainteso qualcosa su come funziona questa cosa implicit operator?

Answer 1

Questo non è specifico per i metodi di estensione. C# non convertirà implicitamente un oggetto in un altro tipo, a meno che non vi sia un indizio sul tipo di destinazione. Supponiamo quanto segue:

class A { 
    public static implicit operator B(A obj) { ... } 
    public static implicit operator C(A obj) { ... } 
} 

class B { 
    public void Foo() { ... } 
} 

class C { 
    public void Foo() { ... } 
} 

Quale metodo ti aspetteresti di chiamare nella seguente dichiarazione?

new A().Foo(); // B.Foo? C.Foo? 

Answer 2

No, non è così, ma la deduzione del tipo del compilatore C# non è abbastanza potente per comprendere il codice e, in particolare, non considera gli operatori impliciti. Dovrai attenersi a Expression<Func<T,bool>> - perché non hai metodi di estensione come Or, And direttamente sulle espressioni?

Answer 3

Come dice Anton, se si mettono i metodi di estensione direttamente su Expression<Func<...>> probabilmente funzionerebbe.

Altre spiegazioni ... niente di particolarmente intelligente, ma l'idea sarebbe che non si dispone di una classe PredicateBuilder di cui si creano istanze. Invece basta blocchi puramente statici:

public static class Predicates 
{ 
    public static Expression<Func<T, bool>> True<T>() 
    { 
     return x => true; 
    } 

    public static Expression<Func<T, bool>> False<T>() 
    { 
     return x => false; 
    } 

    public static Expression<Func<T, bool>> And<T>(
     this Expression<Func<T, bool>> left, 
     Expression<Func<T, bool>> right) 
    { 
     return ... // returns equivalent of (left && right) 
    } 
} 

Queste due funzioni True e False svolgere il ruolo di vostro PredicateBuilder(bool) costruttore, e che ci si presumibilmente avere altri simili per i confronti primitive e così via, e poi operatori come And ti permetterebbe di collegare due espressioni insieme.

Tuttavia, si perde la possibilità di utilizzare i simboli operatore, che si sarebbero potuti usare con l'oggetto wrapper, e invece è necessario utilizzare i nomi dei metodi. Ho giocato con lo stesso tipo di approccio, e la cosa a cui torno sempre è che voglio essere in grado di definire gli operatori di estensione. Il team C# li ha considerati apparentemente per 3.0 (insieme alle proprietà di estensione) ma erano meno prioritari perché non avevano un ruolo negli obiettivi generali di Linq.