Suchergebnisse

Hi und IEquatable<RomanNumber> implementieren auch, sowie GetHashCode überschreiben. Equals(object) ruft Equals(RomanNumber) auf, welches dann entsprechend bspw. den Operator aufruft. Equals(object) erfordert auch eine null-Überprüfung, Equals(RomanNumber) nicht, da eine struct nicht nullable ist, ist ja klar (falls das nicht klar war): C#-Quellcode (14 Zeilen) und IComparable nicht vergessen, wie ich es gerade gemacht habe. Gruß ~blaze~

Type-Converter wär doch eigentlich noch eine Idee. Zum Typ selbst würd's ja in einer Library schon, auch wenn man dann vmtl. den TypeConverter eher auf die Property setzen würde und je nachdem, ob ein numerischer String angegeben wurde, als solchen oder solchen auswerten würde (könnte man doch eigentlich vom von Integer verwendeten TypeConverter ableiten, weiß aber grad nicht, wo der definiert wurde und ob öffentlich und bin zu faul, nachzuschauen). Gruß ~blaze~

Ich würde die Abgeschlossenheit des Frameworks an sich befürworten. Zudem denke ich, dass man darauf achten sollte, die vollständige Funktionalität zu gewährleisten, sofern sie gewünscht wird - ist halt projektabhängig. Wenn man quasi Frameworkkomponenten schreibt - wie hier im Forum - sollte man eigentlich auch diese Kompatibilität mit bestehenden Modellierungen gewährleisten, oder? Wird mir jetzt zu OT für dieses Unterforum. Statische Extensions wären nicht instanzabhängig, sondern eben Erweit…

Die Funktionalität in den Extensions sollte, denk' ich mal, für möglichst abstrakte Fälle gelten. Römische Zahlen wären jetzt nicht unbedingt so abstrakt, dass man sie überall verwenden könnte, auch wenn es ginge. Gruß ~blaze~