I am trying to create a PredicateBuilder
class which wraps an Expression
and provides some methods to easily bu
As Anton says, if you put the extension methods directly on Expression
it would probably work.
More explanation... nothing particularly clever, but the idea would be that you don't have a PredicateBuilder
class that you create instances of. Instead you just have purely static building blocks:
public static class Predicates
{
public static Expression> True()
{
return x => true;
}
public static Expression> False()
{
return x => false;
}
public static Expression> And(
this Expression> left,
Expression> right)
{
return ... // returns equivalent of (left && right)
}
}
Those two functions True
and False
play the role of your PredicateBuilder(bool)
constructor, and you'd presumably have similar ones for primitive comparisons and so on, and then operators like And
would let you plug two expressions together.
However, then you lose the ability to use operator symbols, which you could have used with your wrapper object, and instead you have to use method names. I've been playing around with the same kind of approaches, and the thing I always come back to is that I want to be able to define extension operators. The C# team apparently considered these for 3.0 (along with extension properties) but they were lower priority because they didn't play a part in the overall aims of Linq.