Ainsi, une méthode d'extension assez commun pour IEnumerable, Run:
public static IEnumerable<T> Run<T>(this IEnumerable<T> source, Func<T, T> action)
{
return source.Select(action).ToList().AsEnumerable();
}
4 Réponses :
Essayez la surcharge de droite:
public static IEnumerable<TDest> Run<TSource, TDest>(this IEnumerable<TSource> source,
Func<TSource, TDest> action)
{
return source.Select(action).ToList();
}
Ne fait pas le moindre de la différence.
Vous devez supprimer le .toliste ici, pour éviter d'exécuter la requête
Le nom de la méthode @steveb est exécuté, mais pas Lazyrun
Je ne peux pas répondre pourquoi mais pour résoudre l'ambiguïté, vous pouvez expliquer explicitement votre fonction: ou utilisez une lambda
Je ne sais pas pourquoi il ne peut pas le résoudre automatiquement, mais voici deux travaux de contournement: Pourquoi avez-vous besoin de ces méthodes? Ce qui ne va pas avec: la lisibilité de celui-ci est beaucoup mieux. Sauf si vous avez une bonne raison pour avoir besoin de la méthode , je vous recommanderais de l'utiliser. D'après ce que j'ai vu, il n'y a pas une telle raison, au moins pour la action
Exécuter est une opération de déclaration courante de style fonctionnel, et je ne suis pas d'accord sur le fait que la forme foreach est plus lisible. De plus, une fois que vous avez mis les accolades, il s'agit de quatre lignes au lieu d'un. Je fais cela pour une demi-douzaine de collections d'enfants; Ajouter une ligne vierge entre chacun et c'est ~ 30 lignes de code, ce qui rend la méthode contenant trop longue, donc je refactorise chacun pour atteindre une méthode distincte. Ensuite, j'ai refactorisez cette méthode pour garder les choses sèches et, hey presto, j'ai de toute façon une méthode de course.
@MarkRendle Votre exécuté () n'est pas très fonctionnel. Une grande partie de la programmation fonctionnelle consiste à écrire des fonctions qui n'ont pas d'effets secondaires. Et exécuté () est utile seulement pour les effets secondaires. Je suis d'accord avec Tim sur ceci: foreach est plus lisible et en utilisant des méthodes telles que exécuter () n'est pas une très bonne pratique.
@svick I respectueusement en désaccord.
@svick Il existe de nombreuses langues et / ou cadres, fonctionnels et autrement, qui ont quelque chose comme la méthode / la fonction d'exécution; Pensez aux méthodes «chacune» de Ruby et de Python, ou la méthode Array.Foreach en JavaScript, ou la fonction de bibliothèque standard pour chaque standard.
@MarkRendle et il y a aussi une raison pour laquelle il n'y a pas de méthode (extension) sur ienumerable
Cela a déjà été expliqué par Eric et Jon dans les réponses à cette question . Long Histoire Short - Voici comment fonctionne le compilateur C #; Précisément, lors de la gestion de la conversion de groupe de méthodes décidant de la déléguée, il sera converti pour utiliser la résolution de la surcharge, que ne prend pas les types de retour en compte :
Le principe ici est que la convertibilité de groupe de méthode de détermination nécessite la sélection d'une méthode à partir d'un groupe de méthodes utilisant la résolution de surcharge et la résolution de la surcharge ne considère pas les types de retour.
Dans votre exemple compilateur voit les deux
action Func Ajouter < / code>. Cela ajoute à deux choix possibles et, étant donné qu'elle nécessite une erreur appropriée est émise.
Quelle est la signature de
db.invoicepitems.add ?Réponse courte:
x => x.tostring () Si cette Lambda invoque simplement ou invoquer la touche et renvoyer son résultat? En d'autres termes, cette Lambda devrait-elle être traitée comme une fonction de fonctionnement ou une action? Le compilateur ne peut pas prendre cette décision pour vous donc donc une erreur.@Polity mais il n'y a pas de Lambda ici. Et la conversion d'un groupe de méthodes à un délégué ne peut jamais modifier une méthode qui retourne à quelque chose dans un
Void -returning délégué.@svick - Les Lambdas sont des citoyens étranges dans l'écosystème .Net. Seulement ils dépendent du type déclaré (par conséquent, vous n'êtes pas autorisé à utiliser var). Une lambda affectée à une action ne revient tout simplement pas. Lorsque la résolution de la surcharge doit choisir entre une action et un func, il devient vraiment un choix laid. Maintenant, je suppose que le compilateur détecte ces problèmes à l'avance et génère donc l'erreur.
@Polity Je crois que la réponse de Eric Lippert à la question de la question est liée à la décrire très bien ce problème.