Frühlingsrolle hat folgendes geschrieben :

Das Problem besteht nicht darin, nicht zu wissen, wann ich ein struct und wann eine class verwenden soll, vielmehr fällt es mir schwer, Dinge in .NET umzusetzen, die in Objective Pascal leichter/anders von der Hand gehen. Dort wäre ich auf den TypeConverter nicht angewiesen und könnte sehr wohl auf die Art eine Eigenschaft bereitstellen

Eigentlich ist der Unterschied zwischen Delphi und .NET an der Stelle relativ klein. In beiden Fällen wird bei Verwendung in einer property eine Kopie des structs beziehungsweise Records zurückgegeben, deren Eigenschaften man nicht verändern kann.

Und auch für den Objektinspektor brauchst du dann eine entsprechende Hilfsklasse um Dsten des Records anzuzeigen oder zu modifizieren.

- Nachträglich durch die Entwickler-Ecke gelöscht -

Im generischen TypeConverter fehlt irgendwie der Weg zurück? Man muss ja nicht nur seinen Typ in einen string umwandeln können sondern auch zurück also string nach Typ.
Ich hab mal dein Beispiel vervollständigt mit den Dingen die ich für fehlend halte.

Ich muss aber sagen das ich die Idee merkwürdig finde den Designtime Code im eigentlichen Typen unterzubringen.
Der muss im späteren Code nicht mit ausgeliefert werden sollte daher woanders hin (andere Assembly), der TypeConverter selber wäre da der übliche verdächtige. Einfach einen BasisConverter erstellen und dann davon Ableitungen erzeugen für die konkreten Klassen. Ist nicht mehr Code als so und der Design Code ist sauber vom eigentlichen Code getrennt.

Um eine Instanz des Typen zu erzeugen ist so auch ein doofer Hack nötig. Man kann natürlich ein Methode zum erzeugen dem Interface hinzufügen aber das gehört ja zwingend zu einer Instanz der Klasse um also über ein Interface einen passenden Typen erzeugen zu können muss man erstmal eine Instanz erzeugen (über den Standardkonstruktor) um eine passende Instanz erzeugen zu können

- Nachträglich durch die Entwickler-Ecke gelöscht -