nicht angemeldet
Das bedeutet eben, dass zwar sie *an dieser Stelle nicht definiert* sind, aber der Wert von woanders geholt werden soll (z.B. von einem Default-Objekt d). ... Natürlich würde das auch mit null funktionieren...
Genau dafür verwende ich null und würde das auch jedem raten.
Sämtlicher JavaScript-Code, den ich bisher gelesen habe, macht das auch so. undefined wird so gut wie nie absichtlich verwendet, um eine Objekteigenschaft als »noch leer« zu initialisieren. Ich würde behaupten, dass es eine Konvention ist, null zu verwenden.
Wenn etwas gesetzt ist, aber keinen Wert hat, dann sollte man null verwenden.
...aber null steht ja üblicherweise für ein nicht vorhandenes *Objekt*.
Das sehe ich nicht so. Diese Logik geht auch nicht auf. null macht keine Aussage darüber, für was es ein Platzhalter ist. In einer dynamisch getypten Sprache wäre das auch Quatsch. Dass typeof null 'object' ergibt, wird von vielen einfach als Fehler angesehen. Es ist jedenfalls kein Argument dafür, dass null nur als Platzhalter für Objects herhalten darf. Ich nutze es als Platzhalter auch für Primitives und halte das für sinnvoll, vor allem die Abgrenzung zu undefined.
null benutze ich so: Hier ist noch nichts bzw. hier ist absichtlich nichts. undefined hingegen ist etwas anderes. Funktionen, die nichts zurückgeben, geben standardmäßig undefined zurück. Man kann nur null zurückgeben, wenn man »kein Wert« ausdrücken will. Man kann nur null als Parameter übergeben, um zwischen »absichtlich kein Wert« und »nichts übergeben« zu unterscheiden.
undefined ist ein Wert, der sprachintern bereits mit viel Bedeutung überladen ist. null ist hingegen immer dann nötig, wenn der Programmierer absichtlich »kein Wert« sagen will. Deshalb verwenden sämtliche mir bekannten APIs auch im großen Stil null (DOM habe ich schon genannt, aber auch große JavaScript-Frameworks).
Mathias
Struppi