Why is the Predicate <> sealed?

I wanted to get a class from Predicate <IMyInterface>, but it looks like Predicate <> is sealed. In my case, I just wanted to return the inverted (!) Result of the assigned function. I have other ways to achieve my goal. My question is what did MS designers think when deciding to print Predicate <>?

Without much thought, I came up with: (a) simplified their testing, just time against compromises (b) "Not bad" can be obtained from the Predicate <>

What do you think?

Update: There are n predicates that are dynamically added to the Predicates list during the initialization phase. Each of them is mutually exclusive (if Abc is added, NotAbc will not be added). I noticed a template that looks like this:

bool Happy(IMyInterface I) {...}
bool NotHappy(IMyInterface I) { return !Happy(I); }
bool Hungry(IMyInterface I) {...}
bool NotHungry(IMyInterface I) { return !Hungry(I); }
bool Busy(IMyInterface I) {...}
bool NotBusy(IMyInterface I) { return !Busy(I); }
bool Smart(IMyInterface I) {...}
bool NotSmart(IMyInterface I) {...} //Not simply !Smart

It’s not that I could not solve the problem, its that I am wondering why I could not solve it in a certain way.

+5
source share
3 answers

Predicate<T>- type of delegate. You can never get from delegates.

Honestly, in any case, this is not like inheritance, so just write a method that returns the inverse of the original. It is so simple:

public static Predicate<T> Invert<T>(Predicate<T> original)
{
    return t => !original(t);
}
+19
source

- . . , :

Predicate<T> p;
Predicate<T> inverted = t => !p(t);
+4

. # , , , .

, , .

. + = Delegate.Combine. , ( ).

+2

All Articles