Pourquoi Func<T,bool> au lieu de Prédicat<T>?

C'est juste une curiosité question, je me demandais si quelqu'un avait une bonne réponse à:

Dans le .NET Framework Bibliothèque de Classe, nous avons par exemple ces deux méthodes:

public static IQueryable<TSource> Where<TSource>(
    this IQueryable<TSource> source,
    Expression<Func<TSource, bool>> predicate
)

public static IEnumerable<TSource> Where<TSource>(
    this IEnumerable<TSource> source,
    Func<TSource, bool> predicate
)

Pourquoi ont-ils utiliser Func<TSource, bool> au lieu de Predicate<TSource>? Semble que le Predicate<TSource> n'est utilisé que par List<T> et Array<T>, tandis que Func<TSource, bool> est utilisé par à peu près tous Queryable et Enumerable méthodes et les méthodes d'extension... qu'est-ce qui?

Oh oui, le manque d'uniformité dans l'utilisation de ces lecteurs me fou trop.

InformationsquelleAutor Svish | 2009-03-20

.net c#func predicate

164

Tout Predicate a été introduit en même temps que List<T> et Array<T>, dans .net 2.0, les différents Func et Action variantes viennent .net 3.5.

De sorte que ceux Func les prédicats sont utilisés principalement pour des raisons de cohérence dans les opérateurs LINQ. Comme de .net 3.5, sur l'utilisation de Func<T> et Action<T> la directive unis:

Faire usage de la nouvelle LINQ types Func<> et
Expression<> au lieu de la coutume
les délégués et les prédicats
- Cool, jamais vu ces guildelines avant =)
- Accepte cette réponse, car il a plus de voix. et parce que Jon Skeet a beaucoup de rep... :p
- C'est bizarre de directive comme l'a écrit. Sûrement, il doit indiquer "Ne pas utiliser le nouveau LINQ types "Func<>" et "Action<>" [...]". L'Expression<> est une chose complètement différente.
- Bien, en fait, vous devez le placer que dans le contexte de la directive, qui est de l'écriture d'un fournisseur LINQ. Donc oui, pour les opérateurs LINQ, la ligne directrice est d'utiliser la touche Func<> et l'Expression<> en tant que paramètres pour les méthodes d'extension. Je suis d'accord, j'apprécierais une directive distincte sur l'utilisation de la touche Func et l'Action
- Je pense que Skeet point est que l'Expression<> n'est-ce pas une ligne directrice. C'est un compilateur C# fonction pour reconnaître ce type et en faire quelque chose de différent avec elle.
- Le point de la directive est-à-dire que lors de l'application des opérateurs LINQ, il faut utiliser la touche Func<> et l'Expression<Func<>>.
- Ils devraient faire un type de match pour l'échange entre ces deux.
InformationsquelleAutor Jb Evain
113

J'ai demandé cela avant. J'aime la Predicate<T> délégué - c'est agréable et descriptif. Cependant, vous devez tenir compte de la surcharge de Where:
```
Where<T>(IEnumerable<T>, Func<T, bool>)
Where<T>(IEnumerable<T>, Func<T, int, bool>)
```
Qui vous permet de filtrer sur la base de l'indice de l'entrée ainsi. C'est agréable et cohérente, considérant ce qui suit:
```
Where<T>(IEnumerable<T>, Predicate<T>)
Where<T>(IEnumerable<T>, Func<T, int, bool>)
```
ne serait pas.
- Prédicat<int, bool> serait un peu laid - un prédicat est généralement (IME des sciences de l'informatique) est fondée sur une valeur unique. Il pourrait être Prédicat<Paire<T,int>> bien sûr, mais c'est encore plus laid 🙂
- tellement vrai... hehe. Non, je suppose que la touche Func est plus propre.
- Accepter l'autre réponse en raison des lignes directrices. Souhaite que je pourrais cocher plus d'une réponse si! Ce serait bien si je pouvais marquer un certain nombre de réponses "Très remarquable" ou "ayant Également un bon point qui doit être noté, en plus de la réponse"
- Hm, juste vu que j'ai écrit que le premier commentaire à tort 😛 ma suggestion était bien sûr va être Prédicat<T, int>...
- Je sais que cette question est vieux et tout, mais de savoir ce qui est ironique? Le nom du paramètre dans la Where méthode d'extension est predicate. Heh =P.
InformationsquelleAutor Jon Skeet
30

Sûrement la raison pour l'utilisation de Func au lieu d'un délégué spécifique est que C# traite séparément déclaré les délégués totalement différents types.

Même si Func<int, bool> et Predicate<int> les deux ont le même argument et types de retour, ils ne sont pas compatible avec l'assignation. Donc, si chaque bibliothèque a déclaré son propre type de délégué pour chaque modèle de délégué, ces bibliothèques ne serait pas en mesure d'interopérer, à moins que l'utilisateur insère la "transition" délégués d'effectuer des conversions.
```
    //declare two delegate types, completely identical but different names:
    public delegate void ExceptionHandler1(Exception x);
    public delegate void ExceptionHandler2(Exception x);

    //a method that is compatible with either of them:
    public static void MyExceptionHandler(Exception x)
    {
        Console.WriteLine(x.Message);
    }

    static void Main(string[] args)
    {
        //can assign any method having the right pattern
        ExceptionHandler1 x1 = MyExceptionHandler; 

        //and yet cannot assign a delegate with identical declaration!
        ExceptionHandler2 x2 = x1; //error at compile time
    }
```
En encourageant tout le monde à utiliser la touche Func, Microsoft espère que cela va résoudre le problème de l'incompatibilité des types délégués. Tous les délégués jouent bien ensemble, parce qu'ils seront appariés sur la base de leurs paramètres/types de retour.

Il ne résout pas tous les problèmes, car Func (et Action) ne peut pas avoir out ou ref paramètres, mais ceux qui sont moins fréquemment utilisés.

Mise à jour: dans les commentaires Svish dit:

Encore, la commutation d'un type de paramètre de
Func pour Prédicat et
de retour, ne semblent pas tout
la différence? Au moins il encore compile
sans aucun problème.

Oui, aussi longtemps que votre programme n'attribue méthodes pour les délégués, comme dans la première ligne de mon Main fonction. Le compilateur silencieusement génère un code à nouveau un délégué de l'objet qui la transmet à la méthode. Donc, à mon Main fonction, je pourrais changer de x1 pour être de type ExceptionHandler2 sans causer un problème.

Cependant, sur la deuxième ligne j'essaie d'attribuer le premier délégué à un autre délégué. Même pensé que 2e délégué type a exactement le même paramètre et types de retour, le compilateur donne erreur CS0029: Cannot implicitly convert type 'ExceptionHandler1' to 'ExceptionHandler2'.

Peut-être cela va le rendre plus clair:
```
public static bool IsNegative(int x)
{
    return x < 0;
}

static void Main(string[] args)
{
    Predicate<int> p = IsNegative;
    Func<int, bool> f = IsNegative;

    p = f; //Not allowed
}
```
Ma méthode IsNegative est une très bonne chose pour l'attribuer à la p et f variables, aussi longtemps que je le faire directement. Mais alors je ne peux pas attribuer un de ces variables à l'autre.
- Encore, la commutation d'un type de paramètre de Func<T, bool> à Prédicat<T> et à l'arrière, ne semble pas faire une différence? Au moins il encore se compile sans problèmes.
- Semble MME tentent de décourager les développeurs de la pensée, ce sont les mêmes. Je me demande pourquoi?
- La commutation du type de paramètre ne fait pas de différence si l'expression que vous êtes de passage à elle a été définie séparément à l'appel de la méthode, car alors il sera tapé comme Func<T, bool> ou Predicate<T> plutôt que d'avoir le type inféré par le compilateur.
InformationsquelleAutor Daniel Earwicker
28

Les conseils (en 3.5 et ci-dessus) est d'utiliser la Action<...> et Func<...> - pour le "pourquoi?" - l'avantage est que la "Predicate<T>" n'a de sens que si vous savez ce que "prédicat" signifie - sinon, vous avez besoin de regarder l'objet navigateur (etc) pour trouver la signatute.

À l'inverse Func<T,bool> selon un modèle normalisé; je peux le dire immédiatement que c'est une fonction qui prend un T et renvoie un bool - n'ont pas besoin de comprendre toute la terminologie - il suffit d'appliquer ma vérité test.

Pour "prédicat", ça aurait été OK, mais j'apprécie la tentative de standardiser. Il permet aussi beaucoup de la parité avec les méthodes associées dans ce domaine.

InformationsquelleAutor Marc Gravell

Vous devez vous connecter pour publier un commentaire.