Namensräume
« | 12 Dec 2018 | »Einer der Gründe, warum im GATE Projekt alle Funktionen und Typennamen so verflucht lange sind, liegt an der Tatsache, dass die Sprache C keine Namensräume anbietet.
Es bleibt einem gar nichts anderes übrig, als den Namensraum als Teil des Funktions- oder Typennamens zu kodieren.
Blickt man tiefer in die IT, stellt man fest, dass Namensräume ein gängiges Konzept in fast allen Bereichen sind, um Datenstrukturen zu ordnen.
Namensräume sollen garantieren, dass innerhalb ihrer Grenzen ein
Name eines Elements nur einmal und damit eindeutig vergeben ist.
Hat man keine Namensräume (bzw. nur einen einzigen globalen Namensraum),
so sind Begriffe wie Object
, Program
, File
, Window
,
Array
oder String
schnell an die erste Komponente vergeben und keine
zweite darf dann die gleichen Namen nutzen. So entstehen Konflikte.
Pakt aber jede Komponente “ihre Namen” in einen eigenen Namensraum, sind die Komponenten gegeneinander isoliert und können sich austoben ohne Schaden anzurichten.
C
Schon mal versucht die Header mehrerer Bibliotheken in einer
Übersetzungseinheit einzubinden?
Na dann ist ja dieses Problem bekannt: Doppelte Deklarationen und
defines
.
Beispiel: zwei Header, zwei konträre Ansätze:
Ja, über so etwas bin ich tatsächlich schon gestoßen.
Zum Glück lösen heutige Bibliotheken das mit dem oben erwähnten Ansatz,
einen “Namensraum” vor die Bezeichner zu packen.
Das sähe dann so aus:
Schon haben wir zwei Namen, die sich nicht mehr in die Quere kommen können, allerdings zum Preis eines längeren Bezeichnernamens.
Aus diesem Grund typedef
t das GATE Projekt alles mit dem Präfix gate_
.
z.B.: gate_int32_t
Denn eines der Ziele des Projekt ist es, mit allen möglichen anderen
Bibliotheken gemeinsam eingesetzt zu werden.
C++
Mein Liebling C++ führt mit dem Konstrukt namespace { ... }
die Möglichkeit
ein, den eigenen Code in eine Kategorie zu packen. Von innerhalb des Namensraums
sind alle Elemente mit ihrem kurzen Namen ansprechbar, von außerhalb muss der
Namensraum gefolgt von Doppelpunkten adressiert werden.
(Das using
Schlüsselwort sei auch erwähnt, aber hier nicht weiter beschrieben.)
Java und dotNET
Unter Java sind Packages
das Äquivalent von Namensräumen, während sie in
C# und dotNet wie in C++ auch
namespace
heißen. Doch anstatt von Doppelpunkten kann man die Elemente mit dem
Punkt-Operator adressieren.
Von daher nichts außergewöhnliches.
Windows API
In Windows können manche Systemobjekte durch Angabe eines Namensraums-Präfix
in ihrem Verhalten abgeändert werden. Benannte
Semaphoren, Events und
Mutexe dürfen mit dem Präfix
Global\
oder Local\
starten um Session-übergreifend oder pro Session
ansprechbar zu sein.
Auch gestattet uns das OS
weitere Namensräume
anzulegen und mit
Security-Deskriptoren
gegen Zugriffe zu schützen.
Anwendungsbibliotheken allgemein
Namensraum-Präfixe sind ein oft genutzter Workaround, um eine API, die Namensräume nicht vorsieht, um eben eine solche zu erweitern.
1int legacy_api_get_something(char const* name, void* buffer); 2 3int wrapper_get_something(char const* name, void* buffer); 4{ 5 char full_name[256]; 6 char const* user_name = get_current_user_name(); 7 sprintf(full_name, "%s/%s", user_name, name); 8 return legacy_api_get_something(full_name, buffer); 9}
Dateisystem
Am interessantesten finde ich, dass viele Menschen quasi instinktiv ihre
Dokumente mit Namespace-Präfixe versehen. Natürlich hat hier jedes
Individuum sein eigenes Muster, doch am häufigsten sind
[Kategorie]_Dateiname.ext
und [Datum]_Dateiname.ext
.
Lustigerweise werden hierfür oft keine Ordner angelegt, die ja
das eigentliche Äquivalent von Namensräumen wären.
Mensch wollen offenbar alles auf einen Blick haben, aber trotzdem
die lexikalische Sortierung nach Kategorien angewendet wissen.
Fazit
Namensräume sind in MUSS in der Programmierung, und ganz besonders bei Bibliotheken. Dort ist es nämlich unverzeihlich, wenn sich zwei Konkurrenten deshalb in die Quere kommen, weil sie wie oben beschrieben das Wort BYTE für sich beanspruchen.