nicht angemeldet
StruppiWenn null als Object definiert ist, dann ist es logischerweise auch der Platzhalter für ein Object.
Nein, dieser Schluss ist überhaupt nicht logisch. Eine solche Einschränkung besteht - wie gesagt - nicht per se und ich wüsste nicht, wieso man sie sich auferlegen sollte.
Um eine konsistente Definition zu erhalten. Wenn ich sage eine Funktion/Methode gibt ein Objekt zurück und null bei Mißerfolg, ist der Typ der Rückgabe immer ein Objekt.
Erstmal ist null nicht »als Object definiert«. null ist ein Primitive vom Typ Null. Lediglich der typeof-Operator klassifiziert diesen Primitive als »object«. In jeder anderen Hinsicht ist es sprachintern kein Object.
Ich bin mir nicht sicher, ob hier überhaupt der Begriff primitive eine Rolle spielt, denn alles ist (bzw in JS kann auch) ein Objekt (sein).
»The ECMAScript language types are Undefined, Null, Boolean, String, Number, and Object.«
http://ecma262-5.com/ELS5_HTML.htm#Section_8
Eben, aber Number, String und Boolean sind auch Objekte.
»4.3.11 null value
primitive value that represents the intentional absence of any object value.
Genau das ist die Defintion für null. Das sehe ich zumindest so.
Gut, da steht »object value«, aber faktisch hat das keine Auswirkung, denn eine Variable/Eigenschaft hat in JavaScript keinen festen Typ.
Deshalb wäre es in der Praxis egal, aber sobald du auf Typgenauigkeit prüfst, spielt das u.U. eine Rolle.
JavaScript ist aber nicht Java. Man kann null zurückgeben, wenn man »keinen Wert« zurückgeben will, selbst wenn der standardmäßige Rückgabewert z.B. ein String ist. Das halte ich auch für sinnvoll. Wenn ich z.B. eine Methode getString habe, dann ist zwischen "" und null ein Unterschied ums Ganze. "" heißt: ein leerer String, null: konnte den gewünschten Wert nicht ermitteln, nicht gefunden o.ä. undefined hieße: Die Methode hat gar keinen Rückgabewert.
Was wäre der Unterschied zwischen nicht ermitteln und nicht gefunden?
In beiden Fällen muss der Rückgabewert null sein.
Diese Bedeutung würde ich im Programm nicht »umdeuten«, z.B. indem undefined als Platzhalter verwendet wird.
var person = {
name : undefined /* noch nicht gesetzt */
};
person.name = window.prompt("Wie heißt du?");
Hier wäre eher ein Leerstring oder null angebracht. prompt() gibt auch null zurück, wenn du auf abbrechen klickst.
undefined ist nur dort sinnvoll, wo der Typ bei der Deklaration nicht feststeht.
Gut, in ECMAScript 3 ist es eh nur eine Konvention, solche Platzhalter anzugeben, schließlich sind sämtliche Objekte erweiterbar. In ECMAScript 5 ist das schon anders, denn man kann das Anlegen neuer Eigenschaften unterbinden.
Ja, und genau dann ist ein Wert für den undefinierten Typ eines Objektes notwendig. Bei einer Zahl oder Zeichenkette kann dies null sein, bei einem Objekt muss es null sein.
Wobei ich die Diskussion bei einer Typschwachen Sprache wie JS, für akademisch halte.
Du kannst zur Laufzeit jeder Variabel, jeden Wert und Typ geben, d.h. man braucht solche Definition nur, wenn man sehr spezielle Abfragen macht, die aber immer auch anders lösbar sind. Ebensogut könnte eine Funktion statt null, false zurückgeben. Es würde in der Praxis keinen Unterschied geben. Insofern ist null lediglich eine zusätzliche dreingabe um dem Javaprogrammier etwas bekanntes mitzugeben.
Ob das also wirklich ein Fehler in der Implementierung ist, wie z.b. Crockford behauptet, kann ich nicht so Nachvollziehen. Da die Forderung (die ja auch Don P schon gestellt hatte, als wir über das gleiche Thema diskutierten) das null ein eigener Typ sein müßte, gar keinen Nutzen bringen würde.
Struppi.