Namensräume

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:

/* lib1.h */
#define BYTE unsigned char
/* lib2.h */
typedef char BYTE;
/* myprogram.c */
#include "lib1.h"
#include "lib2.h"

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:

/* lib1.h */
#define LIB1_BYTE unsigned char
/* lib2.h */
typedef char LIB2_BYTE;

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 typedeft 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 addressiert werden. (Das using Schlüsselwort sei auch erwähnt, aber hier nicht weiter beschrieben.)

namespace gate
{
  typedef long int32_t;
  
  int32_t do_something();
  
  ...
  int32_t foo()
  {
    return do_something();
  }
}

gate::int32_t bar()
{
  return gate::foo();
}

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.

int legacy_api_get_something(char const* name, void* buffer);

int wrapper_get_something(char const* name, void* buffer);
{
  char full_name[256];
  char const* user_name = get_current_user_name();
  sprintf(full_name, "%s/%s", user_name, name);
  return legacy_api_get_something(full_name, buffer);
}

Dateisystem

Am interessantesten finde ich, dass viele Menschen quasi instinktiv ihre Dokumente mit Namespace-Präfices versehen. Natürlich hat hier jedes Individuum sein eigenes Muster, doch am häufigsten sind [Kategorie]_Dateiname.ext und [Datum]_Dateiname.ext.

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


Wenn sich eine triviale Erkenntnis mit Dummheit in der Interpretation paart, dann gibt es in der Regel Kollateralschäden in der Anwendung.
frei zitiert nach A. Van der Bellen
... also dann paaren wir mal eine komplexe Erkenntnis mit Klugheit in der Interpretation!