Qu'en est-il des paramètres de type générique en option en C # 5.0? [fermé]

Question

Juste une pensée.

Ne serait-il utile d'avoir des paramètres de type option en C #?

Cela rendrait la vie plus simple. Je suis fatigué d'avoir plusieurs classes avec le même nom, mais des paramètres de type différents. Aussi VS ne supporte pas cette très Vell (noms de fichiers): -)

Ceci par exemple d'éliminer la nécessité d'un IEnumerable non générique:

interface IEnumerable<out T=object>{
  IEnumerator<T> GetEnumerator()
}

Que pensez-vous?

Answer 1

Je suis sans aucun doute pour cela.

Je suis en train d'écrire des méthodes d'aide pour différents scénarios où je veux passer des références à différents membres et méthodes de classes. Pour ce que je prends, par exemple, un Expression<Func<TIn, TOut>> comme argument à l'aide (qui me permet d'accéder à la méthode avec une expression lambda, gardant ainsi tout fortement typé).

- Je dois actuellement définir une nouvelle méthode d'assistance pour chaque nombre différent d'arguments d'entrée, étant donné que je dois avoir un montant différent des arguments génériques à elle. Au lieu de

HelperMethod<TIn>(Expression<Action<TIn>> arg) // Yes, C# can distinguish
HelperMethod<TOut>(Expression<Func<TOut>> arg) // these two from eachother
HelperMethod<TIn, TOut>(Expression<Func<TIn, TOut>> arg)
HelperMethod<TIn1, TIn2, TOut>(Expression<Func<TIn1, TIn2, TOut>> arg)
// etc

Je pourrais faire avec, au plus, deux méthodes:

HelperMethod<TIn>(Expression<Action<TIn>> arg)
HelperMethod<TOut, TIn1 = DummyType, ...>(Expression<Func<TIn1, ..., TOut> arg)

Dans mon cas, il éviterait beaucoup de duplication de code ...

Answer 2

Quelle serait la principale utilisation de cette fonctionnalité de langage? Je peux voir que cela pourrait aider à certaines tâches administratives comme les noms de fichiers et moins de frappe et tel, mais au-delà, je ne vois pas comment cela serait utile.

En outre, cette fonction compliquerait considérablement les contraintes génériques qui pourraient être placés sur le paramètre de type générique et le type par défaut lui-même aurait à fonctionner comme une sorte de contrainte générique lui-même.

Je pense que cela compliquerait la langue sans offrir aucun avantage réel pour le développeur.

Answer 3

Il est pas clair pour moi ce que vous proposez exactement. À l'heure actuelle il peut y avoir des types avec le même nom mais différents paramètres de type, mais qui ne sont pas liés de quelque façon que par héritage - qu'est-ce que votre proposition faire alors

En outre, si la bibliothèque de classes de base ont été redessinés à partir du sol, il certainement serait pas d'interface IEnumerable non générique - il existe seulement parce que le CLR ne prend pas en charge les médicaments génériques lors de l'introduction de l'interface, et l'interface générique en hérite seulement pour que le code existant continuera à travailler. les classes nouvellement déclarées sont créées pour un CLR qui fait des génériques de soutien, de sorte que cette question ne soit plus pertinent.

Answer 4

Je suis récemment tombé sur un cas qui aurait pu utiliser quelque chose comme ça, mais pas tout à fait. I eu un procédé qui effectue une transformation en quelque sorte, entre la classe A et sa classe associée unenfant et de classe B et de classe BChild. En général, la paire A / unenfant était le même que B / BChild, mais parfois était une classe de base de B et unenfant une classe de base de BChild.

Il aurait été agréable de pouvoir dire que mon TB paramètre de type par défaut à TA, et que TBChild par défaut à TAChild.

Notez que ce fut une situation où il fallait écrire les paramètres de type, comme l'inférence ne fonctionnerait pas.