1. Accueil
  2. Question et réponse
  3. Qu'en est-il des paramètres de type générique optionnels dans C# 5.0?

Qu'en est-il des paramètres de type générique optionnels dans C# 5.0?

2010-03-29 5 views
8

Juste une pensée.Qu'en est-il des paramètres de type générique optionnels dans C# 5.0?

Ne serait-il pas utile d'avoir des paramètres de type optionnels 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) Ce serait 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?

Source

2010-03-29 Lars Corneliussen

+0

Dans votre exemple , comment distingueriez-vous entre 'IEnumerable ' et 'IEnumerable'? Le premier serait 'IEnumerable <>'? –

+0

typeof (IEnumerable ) == typeof (IEnumerable) == typeof (IEnumerable <>). MakeGenericOrSo (typeof (objet)) –

+0

La solution standard ici pour le problème de nom de fichier, et je pense que l'un sanctionné par l'équipe VS (bien que je ne puisse pas trouver un lien pour le moment), est de sauvegarder le fichier pour AGenericType avec un nom comme AGenericType'4.cs. –

Répondre

3

Je suis définitivement pour.

J'écris actuellement 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 faire, je prends, par exemple, un Expression<Func<TIn, TOut>> comme argument de l'assistant (qui me permet d'atteindre la méthode avec une expression lambda, gardant ainsi tout fortement typé). MAIS - J'ai actuellement besoin de définir une nouvelle méthode d'assistance pour chaque nombre différent d'arguments d'entrée, car j'ai besoin d'une quantité différente d'arguments génériques pour cela.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 pouvais faire 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 ...

Source

2010-04-09 23:38:06

2

Quelle serait l'utilisation principale pour cette fonctionnalité de langue? Je peux voir que cela pourrait aider avec certaines tâches administratives comme les noms de fichiers et moins de dactylographie et autres, mais au-delà je ne vois pas à quel point cela serait utile.

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

Je pense que cela compliquerait le langage sans offrir de réel avantage au développeur.

Source

2010-03-29 22:38:13

+1

Il garderait le type de recherche plus propre. Étant donné A et B : A , B: A dériverait du même type que B –

+0

Le type par défaut serait soumis à toutes les contraintes de sorte que le code suivant pourrait rester ignorant. Il ferait essentiellement IEnumerable le même que IEnumerable (à titre d'exemple, l'utilité réelle de la fonctionnalité vient avec une architecture plus complexe) –

0

Je ne sais pas exactement ce que vous proposez. Actuellement, il peut y avoir des types avec le même nom mais des paramètres de type différents, mais qui ne sont aucunement liés par héritage - que ferait alors votre proposition? En outre, si la bibliothèque de classes de base était entièrement redessinée, il n'y aurait presque certainement pas d'interface IEnumerable non générique - elle n'existe que parce que le CLR ne supportait pas les génériques lors de l'introduction de l'interface, et le générique L'interface n'en hérite que pour que le code hérité continue à fonctionner. Des classes nouvellement déclarées sont créées pour un CLR qui supporte les génériques, de sorte que ce problème n'est plus pertinent.

Source

2010-03-30 14:00:50 kvb

0

Je suis récemment tombé sur un cas qui aurait pu utiliser quelque chose comme ça, mais pas tout à fait. J'ai eu une méthode qui effectue une sorte de transformation, entre la classe A et sa classe associée AChild et la classe B et la classe BChild. Habituellement, la paire A/AChild était la même que B/BChild, mais parfois A était une classe de base de B et AChild une classe de base de BChild.

Il aurait été agréable de pouvoir dire que mon paramètre de type TB est par défaut TA, et que TBChild est par défaut à TAChild. Notez qu'il s'agissait d'une situation dans laquelle il était nécessaire d'écrire les paramètres de type, car l'inférence ne fonctionnerait pas.

Source

2010-04-03 13:56:53

Questions connexes

 Questions connexes