Diese Frage wurde von Marc Gravells Vorschlag angeregt, neue Sprachfeatures auf dieser Site zu posten, um eine allgemeine Meinung dazu zu erhalten.
Die Idee ist, zu sammeln, wenn sie hilfreich sein könnten oder vielleicht gibt es bereits einen anderen Weg, um das zu erreichen, wonach ich suche.
Eine normale Variablendeklaration in VB.Net ist so geschrieben:
%Vor%Ich schlage vor, folgende Form (en) zu erlauben
%Vor%Diese Syntax ist dem Stil von Vb.Net zur Beschränkung von Generics
entlehntNun, der spezielle Fall, an den ich ursprünglich dachte, war, eine bestimmte Teilmenge von Kontrollen zu definieren. Ich wollte eine Schnittstelle für eine Reihe von Kontrollfabriken erstellen, die Kontrollen basierend auf einigen Geschäftsregeln bereitstellen.
Der Verbraucher dieser Steuerelemente würde über die Schnittstelle verlangen, dass alle erstellten Steuerelemente auch eine Reihe von Schnittstellen (nur eine in meinem Fall) implementieren, die all diesen Steuerelementen zusätzliche Funktionen geben, die bei normalen Steuerelementen nicht vorkommen. p>
Es ist erwähnenswert, dass das Folgende derzeit nicht funktioniert.
%Vor%Ich denke, das bedeutet C # als:
%Vor%Der Versuch, "New SpecialTextbox" zurückzugeben, schlägt fehl, da SpecialTextbox nicht in T umgewandelt werden kann.
%Vor%Ich weiß, dass meine Fabriken einfache Steuerelemente zurückgeben können, und ich könnte zur Laufzeit überprüfen, ob sie ISpecialControl implementiert haben, aber das würde Laufzeitprobleme ergeben, die ich lieber zur Kompilierzeit überprüfen würde, da dies eine logische Möglichkeit ist, auch wenn sie nicht aktuell ist ein praktischer
Update: Die Idee ist, dass diese Fabriken in externen (vielleicht sogar Drittanbieter-) Assemblies sitzen könnten und eine Abhängigkeit von beliebigen Steuerbibliotheken eingehen könnten, indem sie Derivate dieser Steuerelemente erzeugen und zurückgeben, die auch ISpecialControl implementieren.
Diese Assemblies könnten durch selbstkonfigurierende Reflektion (Reflection im ersten Durchlauf gefolgt von Konfiguration, die dann in weiteren Läufen verwendet wird) lokalisiert und ohne Wissen der aufrufenden Assembly verwendet werden, um festzustellen, welche Abhängigkeit diese Steuerelemente genommen hätten / p>
Es erfordert, dass diese Fabriken konstruierbar sind, ohne Informationen über die Kontrolle, die sie nennen sollen, weiterzuleiten, da dies den Punkt besiegen würde.
Was meinst du ... wäre das nützlich? ... Gibt es einen besseren Weg, dies zu erreichen? Gibt es dafür schon einen Weg?
Ich denke, während oberflächlich nützlich, wird diese Art von Sache besser von einem der beiden gehandhabt:
Ihr ursprüngliches Beispiel erfordert keines und kann leicht wie folgt funktionieren:
%Vor%Da die meisten Steuerelemente einen öffentlichen Standardkonstruktor haben, können Sie es sogar noch einfacher machen:
%Vor%Angesichts der zusätzlichen Einschränkung, dass der aufrufende Code nicht direkt eine Referenzabhängigkeit von SpecialTextBox übernimmt, funktioniert das nicht.
Es ist mehr "eingeschränkte Variablen" als "eingeschränkte Typen" - aber definitiv interessant. Wie bei generischen Constraints gibt es wahrscheinlich ein paar kleine Fehler mit der Auflösung, wenn es widersprüchliche Member gibt, aber die gleichen Problemumgehungen würden vermutlich gelten wie bei generischen Constraints.
Natürlich ist die pragmatische Ansicht, dass Sie bereits eine Umwandlung durchführen können, aber dann müssen Sie die beiden Referenzen auf dem neuesten Stand halten ...
hmm ... interessant.
Wie wäre es mit Schnittstellenzusammenstellung?
Sie haben
%Vor%Wenn es existiert, benutze die Schnittstelle für die Klasse B und mache ein zusammengesetztes
%Vor%ändern Sie die Klasse
%Vor%um die Composite-Schnittstelle zu implementieren (die kein Problem darstellen sollte)
%Vor%Und Sie können die Schnittstelle IAB als Einschränkungstyp verwenden.
Ich verstehe nicht, was Sie vorschlagen, ich denke, das ist mein Problem.
Allerdings klingt es für mich so, als würden Sie ein Steuerelement zurückgeben, das eine bestimmte Schnittstelle implementiert.
Warum können Sie nicht einfach sagen, dass die Methode diese spezifische Schnittstelle zurückgibt? Es klingt für mich, wie Sie sagen, dass "Ich Klassen zurückgeben möchten, die von Control abstammen, und das auch Schnittstelle ISomeInterface implementiert".
Vielleicht ist die Lösung, die Teile von Control, die Sie benötigen, in Ihre eigene Schnittstelle zu extrahieren und anzugeben, dass Sie Objekte zurückgeben möchten, die beides implementieren?
So:
%Vor%Diese letzte Schnittstelle würde angeben, dass Sie ein Objekt benötigen, das beide Basisschnittstellen implementiert, was so klingt, wie Sie wollen, außer dass eine der Anforderungen eine Basisklasse anstelle einer Schnittstelle sein soll.
Ich denke, dass Sie dies nur mithilfe von Schnittstellen lösen können.
Unterscheidet sich dies wesentlich von Erweiterungsmethoden ? Warum nicht einfach die Steuerelemente erweitern?
edit: Oh warte ich habe nicht richtig gelesen, es geht darum, es auf 2 Typen zu beschränken, nicht auf 2 Typen. Ich denke, du könntest es ähnlich wie die unten erwähnte Klasse lösen, aber ...
Ich habe einmal mit einer Klasse experimentiert, um dieses Verhalten zu simulieren:
%Vor%, mit dem Sie Konstrukte wie folgt erstellen können:
%Vor% Der Nachteil der impliziten Operatoren ist, dass sie kein implizites Casting für eine Schnittstelle ausführen (es funktioniert auch Casting von einem Interface-Typ), also würde das Eingeben von IEnumerable<T> anstelle von string[] beim Versuch nicht funktionieren um den enthaltenen Wert von Choice<IEnumerable<T>, T> auf IEnumerable<T> zurückzuwerfen.
Im Allgemeinen würde ich lieber Überladungen / Schnittstellen BTW verwenden, also verstehen Sie mich nicht falsch hier:)
Es wäre sinnvoller, wenn Sie Eigenschaften verwenden (und deshalb nicht überladen können), etwa eine DataSource-Eigenschaft, die beispielsweise nur list<string> oder list<ListItem> erlaubt.
Es scheint ein nützliches Sprachmittel zu sein. Es ist möglich, Methodenparameter zu haben, deren Typ unbekannt ist, abgesehen von der Einhaltung mehrerer Abhängigkeiten, aber es gibt keine Möglichkeit, einen solchen Parameter in einem Feld so zu speichern, dass er jemals an eine solche Funktion übergeben oder sogar typisiert werden kann bestanden.
Es gibt jedoch einen anderen Weg, um das grundlegende Ergebnis zu erreichen, das Sie suchen, obwohl es ein wenig klobig ist. Siehe meine Frage Speichern eines Objekts, das implementiert mehrere Schnittstellen und leitet sich von einer bestimmten Basis (.net) ab, wo bieten den besten Ansatz, den ich formuliert haben konnte.
Tags und Links c# vb.net types constraints