Das teuflische Wort 'Optional'

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. 😉