Frage

Nur so ein Gedanke.

Wäre es nicht sinnvoll sein, optional Typparameter in C # haben?

Das würde das Leben einfacher machen. Ich bin müde von mit dem gleichen Namen mehr Klassen haben, aber unterschiedlichen Typparameter. Auch VS unterstützt dies nicht sehr vell (Dateinamen): -)

Dies würde beispielsweise eliminieren die Notwendigkeit einer nicht-generischen IEnumerable:

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

Was denken Sie?

War es hilfreich?

Lösung

Ich bin auf jeden Fall für sie.

Ich schreibe momentan Hilfsmethoden für verschiedene Szenarien, in denen möchte ich Verweise auf verschiedene Mitglieder und Methoden der Klassen zu übergeben. Um dies zu erreichen Ich nehme zum Beispiel eines Expression<Func<TIn, TOut>> als Argument an die Helfer (das lässt mich die Methode mit einem Lambda-Ausdruck zu erreichen, also alles, was stark typisierte halten).

ABER - ich brauche derzeit ein neues Hilfsmethode für jede unterschiedliche Anzahl von Eingabeargumente zu definieren, da ich eine unterschiedliche Menge an generischen Argumente, um es zu haben brauchen. Statt

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

Ich konnte mit dem auskommen, höchstens zwei Methoden:

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

In meinem Fall wäre es eine Menge Code-Duplizierung ...

vermeiden

Andere Tipps

Was wäre die Hauptanwendung für diese Sprache-Funktion sein? Ich kann sehen, dass es mit einigen administrativen Aufgaben wie Dateinamen und weniger tippen und so helfen kann, aber darüber hinaus, dass ich nicht sehen, wie nützlich diese wäre.

Auch würde diese Funktion wesentlich keine generischen Einschränkungen erschweren, die auf dem generischen Typparameter und der Standardtyp selbst würde als eine Art generischer Einschränkung auf Funktion gesetzt werden könnten selbst.

ich denke, das die Sprache erschweren würde, ohne einen wirklichen Nutzen für den Entwickler anbieten.

Es ist mir nicht klar, was genau Sie vorschlagen. Derzeit kann es Typen mit dem gleichen Namen, aber unterschiedlichen Parameter des Typs sein, aber die nicht in irgendeiner Weise durch Vererbung im Zusammenhang - was wäre Ihr Vorschlag dann tun

Außerdem, wenn die Basisklasse Bibliothek von Grund auf neu gestaltet wurden, würde es mit ziemlicher Sicherheit keine nicht-generische Schnittstelle IEnumerable - es existiert nur, weil die CLR nicht Generika unterstützen, wenn die Schnittstelle eingeführt wurde, und die generische Schnittstelle erbt von ihm nur so wird der Legacy-Code zu arbeiten fortzusetzen. Neu deklariert Klassen für eine CLR erstellt werden, die Unterstützung Generika der Fall ist, so dass Problem nicht mehr relevant ist.

Ich kam vor kurzem in einem Fall, dass gebrauchte etwas davon haben könnte, nur nicht ganz. Ich habe ein Verfahren, das führt eine Transformation der Art, zwischen Klasse A und der zugehörigen Klasse AChild und Klasse B und Klasse BKINDER. Üblicherweise wird das Paar A / war AChild die gleiche wie B / BKINDER, aber manchmal A war eine Basisklasse B und AChild eine Basisklasse von BKINDER.

Es wäre schön gewesen, muß in der Lage sein zu sagen, dass mein Typ Parameter TB TA Verzug geraten, und dass TBChild zu TAChild Verzug geraten.

Beachten Sie, dass dies eine Situation, in der es notwendig war, die Typparameter zu schreiben, als Folgerung würde nicht funktionieren.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top