J'ai été à la recherche à F# récemment, et bien que je ne suis pas susceptibles de sauter la barrière du temps, cela met en évidence certaines zones où C# (ou bibliothèque) pourrait rendre la vie plus facile.
En particulier, je suis en train de penser à propos de la correspondance de motif capacité de F#, ce qui permet une très riche de la syntaxe beaucoup plus expressive que le commutateur de courant/conditionnel C# équivalents. Je ne vais pas essayer de donner un exemple direct (ma F# n'est pas à la hauteur), mais en bref, il permet de:
- match par type (avec la couverture de la vérification pour les victimes de syndicats) [note ce a également déduit le type de la variable liée, donnant accès membres, etc]
- match par le prédicat
- combinaisons de ce qui précède (et éventuellement d'autres scénarios que je ne suis pas au courant)
Alors qu'il serait agréable pour C# pour finalement emprunter [hum] une partie de cette richesse, dans l'intervalle, j'ai été la recherche de ce qui peut être fait au moment de l'exécution - par exemple, il est assez facile de frapper ensemble, certains objets afin de permettre:
var getRentPrice = new Switch<Vehicle, int>()
.Case<Motorcycle>(bike => 100 + bike.Cylinders * 10) // "bike" here is typed as Motorcycle
.Case<Bicycle>(30) // returns a constant
.Case<Car>(car => car.EngineType == EngineType.Diesel, car => 220 + car.Doors * 20)
.Case<Car>(car => car.EngineType == EngineType.Gasoline, car => 200 + car.Doors * 20)
.ElseThrow(); // or could use a Default(...) terminator
où getRentPrice est un Func<Véhicule,int>.
[note - peut-être le Commutateur/Cas ici, c'est le mal... mais il montre que l'idée]
Pour moi, c'est beaucoup plus clair que l'équivalent de l'aide répétée si/d'autre, ou d'un composite conditionnel ternaire (qui est très salissant pour les non-trivial expressions entre parenthèses à gogo). Il permet également d'éviter un lot de casting, et permet une extension simple (que ce soit directement ou par l'intermédiaire de méthodes d'extension) de plus en plus-des rencontres spécifiques, par exemple un InRange(...) match comparable à la VB Sélectionnez...Affaire "de x À y d'utilisation".
Je suis juste en train d'évaluer si les gens pensent qu'il ya beaucoup d'avantages de constructions comme ci-dessus (en l'absence de support de la langue)?
Remarque, en outre, que j'ai joué avec 3 variantes de la ci-dessus:
- un Func<TSource,TValue> version d'évaluation comparables pour la composition ternaire instructions conditionnelles
- une Action<TSource> version comparable à de if/else if/else if/else if/else
- une Expression<Func<TSource,TValue>> version - que le premier, mais utilisable par l'arbitraire fournisseurs LINQ
En outre, en utilisant l'Expression version permet l'Expression de l'arbre-la ré-écriture, essentiellement inline toutes les branches dans un composite unique Expression conditionnelle, plutôt que l'utilisation répétée d'invocation. Je n'ai pas vérifié récemment, mais dans certains début de l'Entity Framework construit me semble nécessaire, car il n'aimait pas InvocationExpression très bien. Il permet également de mieux l'utilisation de LINQ-to-Objets, car il permet d'éviter que plusieurs délégué invocations - tests montrent un match comme ci-dessus (à l'aide de la forme d'Expression) de la scène à la même vitesse [légèrement plus rapide, en fait] par rapport à l'équivalent en C# composite instruction conditionnelle. Pour être complet, le Func<...> à partir de la version 4 fois aussi long que le C# instruction conditionnelle, mais il est toujours très rapide et il est peu probable d'être un goulot d'étranglement majeur dans la plupart des cas d'utilisation.
Je souhaite la bienvenue à toutes les pensées / input / critique / etc sur le dessus (ou sur les possibilités les plus riches de C# support de la langue... en espérant qu' ;-p).
