Symbol

Einführung

Symbol ist in JavaScript ein primitiver Datentyp, der eingeführt wurde, um eindeutige Kennungen zu erstellen. Jedes Symbol ist einzigartig, selbst wenn es mit derselben Beschreibung erzeugt wird. Es dient in erster Linie dazu, Kollisionen von Eigenschaftsnamen in Objekten zu vermeiden – also Fälle, in denen mehrere Teile eines Programms versehentlich denselben Schlüsselnamen verwenden.

Was ist ein Wert in JavaScript?

Zuerst sprechen wir und erinnern uns an ein paar allgemeine Konzepte und Gegebenheiten aus dem Bereich Computer Science!

Der Speicher

Bevor wir über Symbole sprechen können, müssen wir kurz ins Gedächtnis holen, wie ein Computer überhaupt Daten speichert. Das ist fundamental wichtig, weil ALLES was JavaScript macht - jede Variable, jedes Objekt, jedes Symbol - letztendlich nur Bytes im Speicher sind.

Man kann sich den RAM als eine gigantische Straße mit nummerierten Häusern vorstellen. Jedes “Haus” kann genau ein Byte (8 Bits) speichern. Diese “Hausnummern” nennt man Speicheradressen und sie sind in hexadezimaler Notation nummeriert.

In diesem Schema sieht man 8 aufeinanderfolgende Bytes im Speicher. Die Zahl 0x2A an Adresse 0x0001 entspricht der Dezimalzahl 42. Das ist wichtig zu verstehen. Alles im Computer ist nur eine Zahl - ein Buchstabe, ein Symbol, ein Objekt und alles, was man sonst kennt.

Die Adresse 0x0001 bedeutet: Gehe zum Byte Nr. 1 im Speicher. Das 0x am Anfang bedeutet nur “das ist eine hexadezimale Notation”. Hexadezimal ist praktisch für die Verwendung, weil ein Byte (8 Bits) genau durch 2 hexadezimale Ziffern dargestellt werden kann.

Der Pointer

Jetzt wird es etwas interessanter. Ein Pointer (auf Deutsch “Zeiger”) ist einfach eine Speicheradresse. Statt einen Wert direkt zu speichern, speichert man die Adresse wo der tatsächliche Wert liegt. Hier kann wieder die Relation/Analogie zwischen der Adresse zu einem Haus und dem tatsächlichen Haus hilfreich sein.

Ein kleines JavaScript Beispiel.

let x = 42;

Was passiert hier wirklich im Speicher?

Adresse 0x1000: [42]

Variable x speichert 0x1000. Die Variable enthält also nicht die Zahl 42 direkt, sondern sie enthält die Information “der Wert liegt bei Adresse 0x1000”.

Wenn man also nun x verwenden würde, würde Folgendes passieren:

1. JavaScript schaut in die Variable x und findet dort eine Adresse 0x1000
2. JavaScript geht zu Adresse 0x1000
3. JavaScript liest den Wert dort: 42

Diesen Prozess nennt man Dereferenzierung. Man folgt dem Pointer zu seinem Ziel.

Warum ist das wichtig für Symbole? Weil Symbole intern als Pointer funktionieren. Wenn man zwei Symbole vergleicht, vergleicht JavaScript nicht deren Inhalt, sondern deren Adressen. Das macht den Vergleich extrem schnell.

Tagged Values

Jetzt eine wichtige Frage: Woher weiß JavaScript, ob ein Wert im Speicher eine Zahl, ein String, ein Symbol oder ein Objekt ist?

Das Problem ist nämlich beim Speichern der Werte folgendes. Ein Wert bietet so gut wie nie eine eindeutige Interpretationsmöglichkeit, also auch eine Möglichkeit der Herleitung des Typs.

Wenn man nur 42 im Speichert sieht, könnte es sein:

• Die Zahl 42
• Der ASCII-Code für das Zeichen '*'
• Ein Teil einer Speicheradresse
• Etwas ganz anderes

JavaScript muss also irgendwie den Typ des Wertes mit speichern. Die Lösung heißt Tagged Pointers (getaggte oder gekennzeichnete Zeiger).

Die Idee ist interessant und einfach: JavaScript nutzt die “unteren Bits” eines 64-Bit-Werts als “Typ-Marker” (Tag). Die restlichen Bits enthalten den eigentlichen Wert oder einen Pointer.

0000 = Small Integer (SMI)
0001 = Pointer zu Object
0010 = Pointer zu String
0011 = Pointer zu Symbol
... etc

Das bedeutet: Die letzten 4 Bits eines Werts sagen in JavaScript, was für ein Typ das ist. Die restlichen 60 Bits enthalten die eigentlichen Daten.

Veranschaulichen wir das an einem kleinen Beispiel.

let num = 42;
let sym = Symbol("test");

So sehen die Werte wirklich im Speicher aus.

Ebene 1 - Symbol in RAM

Symbol-Objekt Struktur

Schauen wir uns an, wie man ein Symbol erstellt.

let sym = Symbol("mySymbol");

JavaScript muss jetzt ein Symbol-Objekt im Speicher anlegen. Aber was ist ein Symbol-Objekt? Das ist eine Daatenstruktur - eine bestimmte Anordnung von Bytes, die zusammen ein Symbol repräsentieren.

Das passiert intern:

1. JavaScript erstellt einen neuen, einzigartigen “Symbol-Wert”
2. Dieser bekommt eine EINZIGARTIGE ID (bspw. 0x5000)
3. Die Beschreibung mySymbol wird separat gespeichert

Variable sym zeigt auf ==> 0x5000
Adresse 0x5000: [Typ-Tag: Symbol][Eindeutige-ID: 12345][Beschreibung: "mySymbol"]

Hier ist folgender Abschnitt der wichtigste: [Eindeutige-ID: 12345].

Im Speicher sieht das Symbol-Objekt ca. so aus.

+---------+----------------+--------+----------------------------+
| Offset  | Feld           | Wert   | Beschreibung               |
+---------+----------------+--------+----------------------------+
| +0      | Type Tag       | 0x07   | Symbol-Typ                 |
| +4      | Hash           | 0x8A3F | Für Hash-Tables            |
| +8      | Symbol ID      | 23871  | Eindeutige ID              |
| +16     | Flags          | 0x00   | z. B. global flag          |
| +20     | Description*   | 0x6000 | Pointer auf String         |
+---------+----------------+--------+----------------------------+

                                |
                                v
                        Adresse 0x6000:
                        +------------------+
                        | "meinSymbol"     |
                        +------------------+

Gehen wir die einzelnen Felder drüber.

Offset +0 (Type Tag): Das ist ein interner Marker, der der Engine sagt “dies ist ein Symbol”. Jeder Object-Typ hat einen anderen Tag. Das ist zusätzlich zum Pointer-Tag und wird verwendet, wenn man dem Pointer gefolgt ist.

Offset +4 (Hash): Ein vorberechneter Hash-Wert für dieses Symbol. Wenn das Symbol als Property-Key verwendet wird, kann JavaScript diesen Hash sofort verwenden, ohne ihn neu berechnen zu müssen. Das ist eine Performance-Optimierung.

Offset +8 (Symbol ID): Das ist das Herzstück. Diese Zahl ist das, was das Symbol wirklich einzigartig macht! Sie wird nie zweimal vergeben. In diesem Beispiel ist es die 23871.

Offset +16 (Flags): Zusätzliche Informationen. Zum Beispiel: Ist dies ein globales Symbol (von Symbol.for())? Ist es ein Well-Known Symbol (wie Symbol.iterator)? Diese Informationen werden als einzelne Bits gespeichert.

Offset +20 (Description): Ein Pointer zur Beschreibung. Wichtig: Die Beschreibung ist optional und hat keinen Einfluss auf die Identität des Symbols.

Wie wird diese ID generiert? Werfen wir einen Blick auf eine vereinfachte Version.

class Symbol {
    static uint64_t next_id = 0; // Globaler Counter

    uint64_t id;
    String* description;

    Symbol(String* desc) {
        this->id = ++next_id; // Jedes Symbol bekommt eine neue ID
        this->description = desc;
    }
}

Somit ist next_id eine statische Variable, was bedeutet, dass zur Klasse gehört, nicht zu einer einzelnen Instanz. Es gibt nur EINE next_id für ALLE Symbole. Jedes Mal, wenn ein neues Symbol erstellt wird, wird diese Zahl erhöht.

Zwei Symbole vergleichen

Jetzt verstehen wir, wie Symbole gespeichert werden. Aber was passiert, wenn man sie vergleicht?

let symOne = Symbol("test");
let symTwo = Symbol("test");

console.log(symOne === symTwo);

false

Dieser Code gibt false zurück. Warum? Beide haben die gleiche Beschreibung. Wir wissen aber, dass nicht die Beschreibung ein Symbol ausmacht! Schauen wir uns also an, was im Computer passiert.

Was macht die CPU?

Der Prozessor führt die eigentlichen Berechnungen aus. JavaScript Code wird letztendlich zu CPU-Befehlen übersetzt. Hier ist eine vereinfachte Version in Assembly-Sprache (Pseudo-Code).

; Pseudo-Code

LOAD R1, [symOne]       ; Lade symOne in Register R1
                        ; R1 = 0x5000 | 0x3 (Pointer + Tag)

LOAD R2, [symTwo]       ; Lade symTwo in Register R2
                        ; R2 = 0x5100 | 0x3 (anderer Pointer + Tag)

CMP R1, R2              ; Vergleiche die Werte
                        ; 0x50003 === 0x51003 ?
                        ; NEIN

JNE not_equal           ; Springe zu not_equal

Der Vergleich ist ein einziger Maschinenbefehl. JavaScript vergleicht einfach die beiden Pointer-Werte. Weil symOne auf Adresse 0x5000 zeigt und symTwo auf 0x5100, sind sie unterschiedlich.

Symbole als Property-Keys

Warum Symbole als Objekt-Schlüssel?

Bevor wir weiter in die technischen Details eintauchen, müssen wir verstehen, warum Symbole überhaupt als Property-Keys in Objekten verwendet werden können und sollten.

Die Geschichte beginnt mit einem fundamentalen Problem in JavaScript: Namespace-Kollisionen.

In JavaScript sind Objekte die zentrale Datenstruktur. Alles dreht sich um Objekte. Properties werden String-Keys angesprochen. Das war viele Jahre der einzige Weg, Properties zu benennen. Aber genau hier liegt das Problem. Was passiert, wenn zwei verschiedene Teile eines Programms - vielleicht zwei verschiedene Bibliotheken - dieselben Property-Namen verwenden wollen?

Das konkrete Problem

Stellen wir uns vor, wir verwenden eine Bibliothek für Datenvalidierung und eine andere für Datenserialisierung. Beide Bibliotheken wollen an Objekten eine metadata Property hinzufügen.

// Validierungs-Bibliothek
function validateUser(user) {
    user.metadata = {
        validated: true,
        timestamp: Date.now()
    };
}

// Serialisierungs-Bibliothek
function serializeUser(user) {
    user.metadata = {
        format: "json",
        version: 2
    };
}

const user = { name: "John" };
validateUser(user);
serializeUser(user);

// An diesem Punkt ist "metadata" überschrieben
console.log(user.metadata);

{ format: 'json', version: 2 }

Die Validierungs-Informationen sind verloren. Die zweite Bibliothek hat die erste überschrieben, weil beide denselben Strin-Key metadata verwendet haben. Das ist eine Namespace-Kollision.

Natürlich könnte man versuchen, eindeutige Präfixe zu verwenden.

user.__validation_lib_metadata = { ... };
user.__serialization_lib_metadata = { ... };

Aber das ist umständlich, fehleranfällig und letztendlich kann man nie sicher sein, dass nicht doch jemand denselben Präfix verwendet. Außerdem verschmutzt es den öffentlichen Namespace des Objekts.

Die Lösung mit Symbolen

Symbole lösen dieses Problem fundamental, weil jedes Symbol garantiert einzigartig ist.

// Validierungs-Bibliothek
const VALIDATION_META = Symbol("validation.metadata");

function validateUser(user) {
    user[VALIDATION_META] = {
        validated: true,
        timestamp: Date.now()
    };
}

// Serialisierungs-Bibliothek
const SERIALIZATION_META = Symbol("serialization.metadata");

function serializeUser(user) {
    user[SERIALIZATION_META] = {
        format: "json",
        version: 2
    };
}

const user = { name: "John" };
validateUser(user);
serializeUser(user);

// Beide Metadaten existieren nebeneinander
console.log(user[VALIDATION_META]);
console.log(user[SERIALIZATION_META]);

{ validated: true, timestamp: 1762149164569 }
{ format: 'json', version: 2 }

Beide Bibliotheken können ihre eigenen Metadaten speichern, ohne sich gegenseitig zu stören. Obwohl beide Symbole die gleiche Beschreibung haben könnten, sind sie intern völlig unterschiedlich. Es ist unmöglich, dass sie kollidieren.

Wie werden Symbol-Keys gespeichert?

Jetzt wird es noch einmal interessant. Wenn wir ein Symbol als Property-Key verwenden, passiert intern etwas Besonderes. JavaScript behandelt Symbol-Properties anders als String-Properties. Das ist keine willkürliche Design-Entscheidung, sondern hat tiefgreifende Gründe.

Schauen wir uns ein einfaches Beispiel an.

const userId = Symbol("id");
const userName = "name";

const user = {
    [userId]: 123,
    [userName]: "John"
};

Was passiert hier wirklich? JavaScript muss irgendwie beide Properties speichern, aber es behandelt sie intern komplett unterschiedlich.

Die Objekt-Struktur im Detail

Jedes JavaScript-Objekt ist im Speicher nicht einfach ein flacher Haufen von Key-Value-Paaren. Es ist eine komplexe Datenstruktur mit verschiedenen Bereichen. Man kann sich ein Objekt wie ein Haus mit mehreren Stockwerken vorstellen, wobei jedes Stockwerk für einen bestimmten Zweck gebaut wurde.

Stellen wir uns vor, unser user Objekt liegt an der Speicheradresse 0x7000. An dieser Adresse beginnt eine Struktur, die verschiedene Pointer (Verweise) auf andere Speicherbereiche enthält.

Objekt bei Adresse 0x7000:
+---------------------------------+
| Shape/Map Pointer    → 0x7100  | <- Beschreibt die "Form" des Objekts
| Properties Pointer   → 0x7200  | <- String-Properties werden hier gespeichert
| Elements Pointer     → 0x7300  | <- Array-ähnliche numerische Indices
| Symbol Table Pointer → 0x7400  | <- Symbol-Properties werden HIER gespeichert
+---------------------------------+

Der entscheidende Punkt: Es gibt einen separaten Bereich nur für Symbol-Properties. Die Symbol-Properties werden nicht zusammen mit den String-Properties gespeichert, sondern in ihrer eigenen Tabelle.

Schauen wir uns an, wie das konkret aussehen könnte.

String-Properties-Tabelle bei 0x7200

+--------------+---------------+
| String Key   | Value         |
+--------------+---------------+
| "name"       | Pointer zu    |
|              | String "John" |
+--------------+---------------+

Symbol-Properties-Tabelle bei 0x7400

+------------------+--------------+
| Symbol Pointer   | Value        |
+------------------+--------------+
| 0x5000 (userId)  | Number 12345 |
+------------------+--------------+

Wichtig: In der Symbol-Tabelle wird nicht die Beschreibung gespeichert, als nicht id, sondern der Pointer zum Symbol-Objekt selbst (0x5000). Das Symbol-Objekt hat eine eindeutige ID.

Warum diese Trennung?

Diese Architektur-Entscheidung hat mehrere wichtige Gründe:

Grund 1: Performance bei normalen Operationen

Die meisten Operationen in JavaScript arbeiten mit String-Properties. Wenn man user.name schreibt oder Object.keys(user) aufruft, interessieren einen normalerweise nur die String-Properties. Durch die Trennung muss die JavaScript-Engine nicht durch Symbol-Properties iterieren, wenn sie String-Properties sucht. Das macht normale Operationen schneller.

Stellen wir uns vor, wir hätten ein Objekt mit 100 String-Properties und 50 Symbol-Properties. Jetzt machen wir eine Schleife über alle Keys.

for (let key in user) {
    console.log(key)
}

Ohne die Trennung müsste JavaScript durch alle 150 Properties gehen und bei jeder einzelnen prüfen: “Ist das ein String oder ein Symbol”. Mit der Trennung kann JavaScript einfach sagen: “Gehe nur durch die String-Properties”. Die 50 Symbol-Properties werden einfach ignoriert, weil sie in einer anderen Tabelle liegen.

Grund 2: Sichtbarkeit und Privatsphäre

Symbol-Properties sollen bei normalen Enumerationen “unsichtbar” sein. Das ist ein Design-Feature, kein Bug. Wenn jemand Object.keys(user) aufruft, soll er nur die öffentlichen, für ihn gedachten Properties sehen - nicht die internen Metadaten, die Bibliotheken dort gespeichert haben.

Durch die separate Speicherung ist diese Unsichtbarkeit automatisch gegeben. Die Engine muss nicht bei jeder Property prüfen und entscheiden, ob sie sichtbar sein soll oder nicht. Sie schaut einfach nur in die String-Property-Tabelle.

Hier eine kleine Veranschaulichung.

// Symbol als Property-Name definieren
const userSalary = Symbol("salary");

// User Objekt erstellen und normale Properties zuweisen
const user = {};
user.name = "John";
user.age = 40;

// Wert über Symbol zuweisen
user[userSalary] = 40000;

// Sichtbaren Eigenschaften abrufen
console.log(Object.keys(user));

// Salary abrufen
console.log(user[userSalary]);

// Symbole anzeigen
console.log(Object.getOwnPropertySymbols(user));

[ 'name', 'age' ]
40000
[ Symbol(salary) ]

Wie man hier sehen kann, sind die Symbol-Properties standardmäßig nicht sichtbar, also nicht “enumerable”.

Grund 3: Optimierungsmöglichkeiten

JavaScript-Engines können String-Properties und Symbol-Properties unterschiedlich optimieren. String-Properties werden häufig in “Inline-Caches” gespeichert, weil sie oft verwendet werden. Symbol-Properties brauchen diese Optimierung meist nicht, weil sie seltener angesprochen werden. Durch die Trennung kann die Engine für jeden Typ die optimale Strategie wählen.

Property-Lookup verstehen

Wenn JavaScript eine Property lesen will, muss es diese zunächst finden. Dieser Prozess heißt Property Lookup (Eigenschaftssuche). Je nachdem, ob es sich um einen String oder ein Symbol handelt, läuft dieser Prozess unterschiedlich ab.

console.log(user.name);

console.log(user[userId]);

Der entscheidende Unterschied: Bei Strings muss die Tabelle nach einem String-Match durchsucht werden (Zeichen für Zeichen vergleichen). Bei Symbolen wird nach einem Pointer-Match gesucht (einfacher Integer-Vergleich).

Warum ist Symbol-Loopup schneller?

Beim String-Vergleich muss JavaScript potenziell jeden Buchstaben vergleichen. Beim Symbol-Vergleich ist es ein einziger numerischer Vergleich.

Sichtbarkeit von Symbolen

Das Konzept der Sichtbarkeitsebenen

Eines der wichtigsten Features von Symbolen ist ihre gesteuerte Sichtbarkeit. Sie sind nicht einfach “unsichtbar” oder “versteckt” - es gibt verschiedene Ebenen der Sichtbarkeit und verschiedene APIs können auf verschiedenen Ebenen zugreifen.

Das ist ein durchdachtes Design-Feature. Symbole sollten bei normalen, alltäglichen Operationen unsichtbar bleiben, um keine Verwirrung zu stiften und keine Namenskonflikte zu verursachen. Aber sie sollten trotzdem zugänglich sein, wenn man explizit danach sucht, zum Beispiel für Debugging oder Reflection.

Schauen wir uns ein Beispiel an.

const publicKey = "name";
const hiddenKey = Symbol("secret");

const user = {
    [publicKey]: "John",
    [hiddenKey]: "topSecretValue"
};

Dieses einfache Objekt hat zwei Properties. Aber je nachdem, wie wir das Objekt betrachten, sehen wir unterschiedlich viele Properties.

Ebene 1: Normale Enumeration - Symbole sind unsichtbar

Die erste und wichtigste Ebene ist die normale Enumeration. Das sind alle Standard-Methoden, die die meisten Entwickler täglich verwenden, um über Objekte zu iterieren oder ihre Keys abzurufen.