Das teuflische Wort 'Optional'
« | 19 Jan 2019 | »Die Standards von Programmiersprachen, Bibliotheken und Komponenten unterscheiden “mandatory” und “optional” Features. Alles was “mandatory” ist muss korrekt implementiert und vorhanden sein. Ist es hingegen nur “optional”, darf es fehlen und ein solches Fehlen darf keine weiteren Probleme verursachen.
Doch wer legt das fest?
Formal betrachtet entscheidet das der Hersteller bzw. Erfinder der Komponente, in der Praxis entscheiden das aber die Endanwender.
Denn wenn ein “optionales” Feature als fundamental angesehen wird und häufig bis überall zum Einsatz kommt, dann kann sich niemand den Luxus leisten, auf das “optionale” Feature zu verzichten.
Im definierten Befehlssatz des
Intel Pentium (586er)
bzw. dessen Nachfolger, dem
Intel Pentium Pro (686er)
gab es einige Befehle, die als “optional” definiert waren.
Als die inzwischen vergessene Chip-Schmiede
Cyrix diese Prozessoren nachbaute,
verzichteten sie auf einige optionale Befehle, was ihre Produkte theoretisch nicht
beeinflussen sollte.
Natürlich kam dann prompt die “nächste” Windows Version auf den Markt, die ohne diese optionalen Befehlssätze nicht mehr lauffähig war und schon hatte die Plattform ein Problem.
Und wer kennt nicht das Chaos, das Microsoft anrichtete, als sie über eine
Dekade darauf verzichteten, optionale C-Header wie <stdint.h> in ihre
Compiler aufzunehmen. Auch wenn es nur eine Hand voll an typedef Anweisungen
waren, meinten viele Entwickler zu Recht, dass der Compiler wegen dieses Mankos
Mist sei und nutzten einen anderen.
<stdint.h> ist
tatsächlich auch nur als “optional” im C Standard erwähnt, doch gerade wegen
seiner Einfachheit ist sein Fehlen kontraproduktiv.
Auch heute noch schleppe ich Ersatz-Header in Unterverzeichnissen von Projekten
herum, die solche optionalen Features bereitstellen, wenn sie nicht vom
Compiler-Hersteller bedacht wurden.
Ein anderes Beispiel war das dotNet-Compact-Framework, das sich vor allem dadurch auszeichnete, dass viele Funktionsüberladungen des “großen” dotNet Frameworks fehlten. Tatsächlich sind viele Überladungen einfach nur “Syntax-Sugar”, man hat eine Funktion mit mehreren Parametern, die wirklich etwas tut, und einige weitere, die einfach nur auf diese erste Funktion verweisen und dabei bestimmte Parameter setzen ohne dass der Anwender sie wissen muss.
Genau das Fehlen dieser Methoden führte dann dazu, dass üblicher dotNet Code nicht mit dem Compact-Framework kompatibel war und neu geschrieben werden musst. Also eigentlich auch eine Form von “optionalen” Features, die einfach zu beliebt waren.
Fazit
Aus Gründen der Kompatibilität und Wiederverwertbarkeit würde ich mir sehr wünschen, dass man auf diese “mandatory/optional” Spielchen so weit wie möglich verzichtet. Ein Feature soll nicht “halb-relevant” sein. Es ist entweder wichtig und muss daher vertreten sein, oder es ist unwichtig und sollte daher unter den Tisch fallen.
Auch wenn ich mich mit dieser Meinung unbeliebt mache, aber:
Weniger ist manchmal mehr!
Und ob man jetzt 3 Prozessorbefehle weniger hat, macht sprichwörtlich
“das Kraut nicht fett” und es muss nicht int64_t heißen, wenn long long
laut Standard garantiert größer gleich 64 bits lang ist. 😉