globale variablen und funktionen

[Markus**]

Hallo Forum,

mit "typeof" lässt sich auf folgende Art und Weise die Typ eines Objekts bestimmen. So liefert z.B.:

var b = 1;  
alert(typeof b);

"number" als Resultat

Hingegen gibt:

  
    var x = new Array;  
    for (var p in this) {  
        x.push(typeof p);  
    }  
    alert(x.join(", "));

string, string, string,.... usw. zurück.

find ich blöd, weil ich mir eigentlich erhofft hatte, alle globalen umgebungsvariabeln auswerten zu können!

Weiß jemand rat?!

Gruß, Markus**

[LX]

Hallo!

Weiß jemand rat?!

Ja. Du willst nicht typeof p, sondern typeof x[p] - ansonsten bekommst Du nur die Identifier.

Gruß, LX

[Markus**]

Hallo!

Ach fuck!

Weiß jemand rat?!

Ja. Du willst nicht typeof p, sondern typeof x[p] - ansonsten bekommst Du nur die Identifier.

darauf bin ich schon so oft reingefallen!
Danle!

Gruß, LX

Gruß!

[Steel]

Hallo!
Ach fuck!

Boah! Bist Du hoeflich!

*scnr* ;)

Was lernen wir daraus? Zitiere richtig. :P

[Markus**]

Hallo!
Ach fuck!

Boah! Bist Du hoeflich!

Ach fuck!

*scnr* ;)

ist "Ach fuck!" denn keine angemessene Begrüßung? :)

Was lernen wir daraus? Zitiere richtig. :P

ich gelobe  Besserung!

Markus**

[Steel]

Hiho!

ist "Ach fuck!" denn keine angemessene Begrüßung? :)

Montagmorgen sicherlich ...

;)

[EKKi]

Mahlzeit Steel,

ist "Ach fuck!" denn keine angemessene Begrüßung? :)

Montagmorgen sicherlich ...

Montags morgens ist die einzig angemessene Begrüßung ein herzhaftes *GRUMMEL* ...

*SCNR*

MfG,
EKKi

[Don P]

Hallo,

mit "typeof" lässt sich auf folgende Art und Weise die Typ eines Objekts bestimmen. So liefert z.B.:

var b = 1;

alert(typeof b);

> "number" als Resultat  
  
Ja, aber `typeof null`{:.language-javascript} liefert leider "object" als Resultat (`null`{:.language-javascript} ist eigentlich kein Objekt), genau wie `typeof []`{:.language-javascript}.  
Ein Array ist zwar auch ein Objekt, aber viel sinnvoller wäre da "array" als Ergebnis.  
  
Gruß, Don P  

[LX]

Arrays kann man leicht folgendermaßen erkennen:

[] instanceof Array // = true

Gruß, LX

[Struppi]

Ja, aber typeof null liefert leider "object" als Resultat (null ist eigentlich kein Objekt),

Doch null ist ein Wert, der ein leeres oder nicht existierendes Objekt repräsentiert.

Struppi.

[Don P]

Hallo,

Ja, aber typeof null liefert leider "object" als Resultat (null ist eigentlich kein Objekt),

Doch null ist ein Wert, der ein leeres oder nicht existierendes Objekt repräsentiert.

Ein leeres Objekt? Was ist *das* denn? Noch nie davon gehört.

var o = {};     // ein "leeres" Objekt ?  
alert(o==null); // false  

null *repräsentiert* zwar in gewisser Weise ein nicht existentes Objekt, *ist* aber selber kein Objekt, sondern ein primitive value.
null hat ja keinerlei Eigenschaften oder Methoden und man kann ihm auch keine verpassen durch prototypische Erweiterung, wie das bei wirklichen Objekten der Fall ist.

Gruß, Don P

[Don P]

Hallo,

null *repräsentiert* zwar in gewisser Weise ein nicht existentes Objekt, *ist* aber selber kein Objekt, sondern ein primitive value

... wie acuh NaN oder undefined.

Eigentlich ist nur eine Konvention, dass man null zurückgibt, wenn ein Objekt erwartet wird, das nicht zur Verfügung steht. Das erhebt null aber noch nicht zu einem Objekt.

Gruß, Don P

[Struppi]

Doch null ist ein Wert, der ein leeres oder nicht existierendes Objekt repräsentiert.

Ein leeres Objekt? Was ist *das* denn? Noch nie davon gehört.

Steht so in der Spezifikation.

4.3.11 Null Value
The null value is a primitive value that represents the null, empty, or non-existent reference.

null *repräsentiert* zwar in gewisser Weise ein nicht existentes Objekt, *ist* aber selber kein Objekt, sondern ein primitive value.

Genau! Es repräsentiert ein object und deshalb hat man sich wohl darauf geeinigt, dass typeof das auch so zurückgibt. Steht im Kapitel 11.4.3

Struppi.

[Don P]

Hallo,

null *repräsentiert* zwar in gewisser Weise ein nicht existentes Objekt, *ist* aber selber kein Objekt, sondern ein primitive value.

Genau! Es repräsentiert ein object und deshalb hat man sich wohl darauf geeinigt, dass typeof das auch so zurückgibt. Steht im Kapitel 11.4.3

Na also, das war doch nur meine Aussage: "null ist eigentlich kein Objekt", und du schriebst "Doch...".

Es ist mir schon klar, dass man sich halt entschlossen hat, typeof so zu definieren. Man hat ja auch beschlossen, dass NaN ("Not a Number") vom Typ "number" sein soll:

alert(typeof NaN); // => number *staun*

In gewisser Weise ist das ja verständlich. Aber z.B. gerade für den Zweck, der im OP beschrieben ist, ist es wenig hilfreich, wenn null oder ein Array als Objekt und NaN als Zahl verkauft wird. Es sind nunmal spezielle Typen und sollten sinnvollerweise von typeof auch als solche genannt werden. So aber ist typeof irgendwie nur "halbgar"... meiner bescheidenen Meinung nach.

Gruß, Don P

[Struppi]

(typeof NaN); // => number *staun*[/code]

In gewisser Weise ist das ja verständlich. Aber z.B. gerade für den Zweck, der im OP beschrieben ist, ist es wenig hilfreich, wenn null oder ein Array als Objekt und NaN als Zahl verkauft wird. Es sind nunmal spezielle Typen und sollten sinnvollerweise von typeof auch als solche genannt werden. So aber ist typeof irgendwie nur "halbgar"... meiner bescheidenen Meinung nach.

Es ist die Frage für was du null verwenden willst.

Für mich ist ein nicht definiertes Objekt, ansonsten hat null eigentlich keine andere Bedeutung. Folglich muss typeof null object ergeben, denn deine ursprüngliche Intention war es ein Objekt zu erhalten.

Struppi.

[Don P]

Hallo,

Es ist die Frage für was du null verwenden willst.

Für mich ist ein nicht definiertes Objekt, ansonsten hat null eigentlich keine andere Bedeutung. Folglich muss typeof null object ergeben, denn deine ursprüngliche Intention war es ein Objekt zu erhalten.

Es ist, wie wenn man den interstellaren Raum zum Typ "Himmelskörper" erklärt, nur weil dort vielleicht mal einer entstehen oder vobeikommen könnte.

Wenn meine Intention ist, ein Objekt zu erhalten, dann will ich sicher nicht null, sondern eben ein Objekt. Wenn ich jetzt z.B. alle nicht definierten "Objekte" löschen will (d.h. solche, die mal ein Objekt werden könnten), muss ich erst alle Objekte untersuchen, ob sie nicht vielleicht wirklich welche sind...

Wenn typeof null === 'null' gelten würde, hätte man dieses Problem nicht und wäre sicher, dass man immer ein echtes Objekt o hat, falls typeof o === 'object' gilt.

Gruß, Don P

[Struppi]

Wenn meine Intention ist, ein Objekt zu erhalten, dann will ich sicher nicht null, sondern eben ein Objekt.

null repräsentiert ein Objekt.

Wenn typeof null === 'null' gelten würde, hätte man dieses Problem nicht und wäre sicher, dass man immer ein echtes Objekt o hat, falls typeof o === 'object' gilt.

var o = document.getElementById('gibtsnicht');
Da soll ein Objekt zurück kommen?
Du willst nicht auf if(!o) testen?

Struppi.

[Don P]

Hallo,

null repräsentiert ein Objekt.

Wenn typeof null === 'null' gelten würde, hätte man dieses Problem nicht und wäre sicher, dass man immer ein echtes Objekt o hat, falls typeof o === 'object' gilt.

var o = document.getElementById('gibtsnicht');
Da soll ein Objekt zurück kommen?

Nein, wieso denn? Ich habe ja nichts dagegen, dass null zurückkommt, wenn kein entsprechendes Objekt existiert. Aber ich habe etwas dagegen, dass typeof den Wert null als Objekt ausgibt. Ein nicht existierendes Objekt ist eben keins, ganz einfach. Da ist es doch Betrug, wenn typeof mir weismachen will, es sei doch eins...

Du willst nicht auf if(!o) testen?

Doch, natürlich. Das könnte ich aber auch, wenn z.B. undefined zurückkäme statt null, und mit typeof hat das ja überhaupt nichts zu tun.

Kann mich gar nicht erinnern, jemals typeof benutzt zu haben. Aber wenn man es doch mal meint benutzen zu sollen, wie hier im OP, dann will man doch sinnvolle Antworten und nicht als Objkete getarnte Nichtse oder als Zahlen verkleidete Nicht-Zahlen oder solchen Quatsch ;)

Gruß, Don P

[Struppi]

Aber ich habe etwas dagegen, dass typeof den Wert null als Objekt ausgibt. Ein nicht existierendes Objekt ist eben keins, ganz einfach. Da ist es doch Betrug, wenn typeof mir weismachen will, es sei doch eins...

Naja, es geht auch z.b., um den Kontext. Da wo die null ist, wird ein Objekt erwartet, da wo NaN ist, eine Zahl. typeof getElementById(...) muss immer 'object' ergeben und nicht mal dies oder jenes.

Kann mich gar nicht erinnern, jemals typeof benutzt zu haben. Aber wenn man es doch mal meint benutzen zu sollen, wie hier im OP, dann will man doch sinnvolle Antworten und nicht als Objkete getarnte Nichtse oder als Zahlen verkleidete Nicht-Zahlen oder solchen Quatsch ;)

typeof benutzte ich eigentlich immer um rauzufinden, ob ein Wert definiert ist. Wenn ich herausfinden möchte ob ein Objekt einen Wert hat, prüfe ich auf null und dabei möchte ich auch keine Typkonvertierung. Die, wie wir ja schon mal diskutiert haben, auch ihre Fallstricke hat.

Ausserdem muss ja auch der Vergleich obj !== null funktionieren und das geht nur, wenn null ein Objekt ist.

Struppi.

[Don P]

Hallo,

Naja, es geht auch z.b., um den Kontext. Da wo die null ist, wird ein Objekt erwartet, da wo NaN ist, eine Zahl. typeof getElementById(...) muss immer 'object' ergeben und nicht mal dies oder jenes.

typeof dient also dazu herauszufinden, was erwartet wird oder was irgendwo stehen könnte? Hmm, das weiß man doch...

typeof benutzte ich eigentlich immer um rauzufinden, ob ein Wert definiert ist.

Ob etwas überhaupt definiert ist prüfe ich, wenn überhaupt nötig, mit if(sth!==undefined)...

Wenn ich herausfinden möchte ob ein Objekt einen Wert hat, prüfe ich auf null und dabei möchte ich auch keine Typkonvertierung. Die, wie wir ja schon mal diskutiert haben, auch ihre Fallstricke hat.

typeof braucht man dafür aber nicht. Die Existenz eines Objekts prüft man am besten mit if(o)... da stört die automatische Typkonvertierung nicht, es sei denn, man hat Variablen, die tatsächlich auch mal einen anderen truthy Wert als ein Objekt enthalten können, aber das wäre ein Spezialfall und m.E. bad practice.

Ausserdem muss ja auch der Vergleich obj !== null funktionieren und das geht nur, wenn null ein Objekt ist.

Wieso? Das geht auch sonst. null ist ja kein Objekt. Es steht nur manchmal da, wo auch ein Objekt stehen könnte, das ist alles. Wie gesagt, es ist kein Problem, dass statt eines Objektes auch mal null zurückkommt; das ist ganz gut so. Deswegen muss typeof noch lange nicht behaupten, dass null auch ein Objekt ist.

Gruß, Don P

[Struppi]

Naja, es geht auch z.b., um den Kontext. Da wo die null ist, wird ein Objekt erwartet, da wo NaN ist, eine Zahl. typeof getElementById(...) muss immer 'object' ergeben und nicht mal dies oder jenes.

typeof dient also dazu herauszufinden, was erwartet wird oder was irgendwo stehen könnte? Hmm, das weiß man doch...

Es geht nicht um typeof, es geht um den Wert. null dient dazu in einem Kontext wo ein Objekt erwartet wird den Nichterfolg anzuzeigen, ansonsten wäre null überflüssig, dann würde auch false reichen.

typeof benutzte ich eigentlich immer um rauzufinden, ob ein Wert definiert ist.

Ob etwas überhaupt definiert ist prüfe ich, wenn überhaupt nötig, mit if(sth!==undefined)...

Fehler: sth is not defined  
Quelldatei: .../tmp.html  
Zeile: 16  

Das geht nicht, wenn sth nicht deklariert wurde. Ich benutze undefined nicht, da es lange Zeit nicht alle Browser konnten, aber das dürfte sich mittlerweile geändert haben.

Ausserdem muss ja auch der Vergleich obj !== null funktionieren und das geht nur, wenn null ein Objekt ist.

Wieso? Das geht auch sonst. null ist ja kein Objekt.

Doch, null ist ein Objekt. Aber es geht um die Theorie. Ein exakter Vergleich prüft auf den Typ, wenn null nicht ein Objekt wäre, gäbe es kein entsprechende Möglichkeit auf exakte Gleichheit zu prüfen.

Struppi.

[Don P]

Hallo,

Es geht nicht um typeof, es geht um den Wert. null dient dazu in einem Kontext wo ein Objekt erwartet wird den Nichterfolg anzuzeigen, ansonsten wäre null überflüssig, dann würde auch false reichen.

Jetzt geht es nicht mehr um typeof? Ich glaube, du verwechselst da etwas. Es ging hier doch überhaupt *nur* um typeof, weil typeof null === 'object' gilt. Das hat zunächst überhaupt *nichts* damit zu tun, dass üblicherweise der Wert null zurückgegben wird, wenn ein entsprechendes Objekt nicht existiert.

false würde tatsächlich ausreichen, man könnte ebensogut 0 oder undefined oder NaN oder halt false zurückgeben, was man in selbstdefinierten Funktionen ja auch machen kann. Trotzdem wäre ein typgenauer Vergleich möglich, z.B. bei Rückgabe von false mit if(obj===false), oder bei NaN mit isNaN(obj). Wo ist da das Problem?

typeof benutzte ich eigentlich immer um rauszufinden, ob ein Wert definiert ist.

Ob etwas überhaupt definiert ist prüfe ich, wenn überhaupt nötig, mit if(sth!==undefined)...

Fehler: sth is not defined

Quelldatei: .../tmp.html
Zeile: 16

  
Ok, weil ich das so selten brauche, hab' ich es prompt falsch hingeschrieben. Hier wäre wirklich mal typeof von Nutzen:  
`if(typeof sth!=='undefined')`{:.language-javascript}...  
  

> Doch, null ist ein Objekt.  

Nein, ist es nicht!  
  

> Aber es geht um die Theorie.  
  
Mir geht es um die Praxis und die normale menschliche Logik. Ein Objekt in JS hat Eigenschaften und/oder Methoden, ggf. einen Prototyp und kann um weitere Eigenschaften und Methoden erweitert werden. null hat von alldem gar nichts, ist nur ein simpler Wert, und so steht es auch in der Spezifikation. Dort steht nämlich nicht, dass null ein Objekt ist. Wäre es eines, dann würde `alert(null.sth);`{:.language-javascript} keinen Fehler werfen, sondern höchstens 'undefined' ausgeben. Nicht einmal `alert(''.sth);`{:.language-javascript} wirft einen Fehler, obwohl der literale Leerstring auch kein Objekt ist, anscheinend aber doch noch objektiger als null.  
  

> Ein exakter Vergleich prüft auf den Typ, wenn null nicht ein Objekt wäre, gäbe es kein entsprechende Möglichkeit auf exakte Gleichheit zu prüfen.  
  
Objekte auf Gleichheit zu prüfen ist doch trivial, denn die müssen ohnehin identisch sein, damit sich true ergibt.  
Aber prüfen wir doch mal:  
~~~javascript
  
alert('' === String(''));        // true  
alert(typeof '' === 'string');   // true  
alert( 0 === Number(0));         // true  
alert(typeof 0 === 'number');    // true  
//Aber:  
alert( NaN === Number());        // false, wie jeder vergleich mit NaN, ok.  
alert(typeof NaN === 'number');  // true => eine Nicht-Zahl ist eine Zahl :(  
alert(null === Object());        // false, ok.  
alert(typeof null === 'object'); // true => ein Nicht-Objekt ist ein Objekt :(  

Viel besser wäre doch:

typeof null === 'null';  
typeof NaN === 'nan';  
typeof [] === 'array';

Schaden würde es wohl nicht, wäre einfach nur logisch.

Nehmen wir z.B. ein Array a mit i Elementen, und jedes Element a[i], das ein Objekt ist, soll um eine Eigenschaft p erweitert werden. Der Code

for (var i in a) { if(typeof a[i]==='object') {a[i].p = p;} }

funktioniert nicht zuverlässig, weil a[i] auch mal null sein könnte, was für typeof aber dummerweise egal ist. Also müssen wir umständlich notieren
if(typeof a[i]==='object' && a[i]!==null)...
was doch eigentlich gar nicht nötig wäre, wenn typeof vernünftige Auskünfte gäbe ^^.

Gruß, Don P

[Struppi]

Es geht nicht um typeof, es geht um den Wert. null dient dazu in einem Kontext wo ein Objekt erwartet wird den Nichterfolg anzuzeigen, ansonsten wäre null überflüssig, dann würde auch false reichen.

Jetzt geht es nicht mehr um typeof?

Nein, es geht darum dass null einzig und allein dazu da ist ein Objekt darzustellen - ein nicht vorhandenes Objekt.

Ansonsten hat dieser Wert keinen anderen Zweck. Deshalb ist der Typ von null ein 'object'. Für mich ist das logisch.

Denn es bedeutet, dass ich Variabeln die ein Objekt beinhalten können immer einen Wert vom Typ 'object' haben.

Ich weiß nicht, für welchen Zweck du null einsetzen möchtest und was du mit den von dir vorgeschlagenen Typen machen willst. Aber ich bin bisher mit dieser Konvention gut und ohne Probleme zu recht gekommen.

Nehmen wir z.B. ein Array a mit i Elementen, und jedes Element a[i], das ein Objekt ist, soll um eine Eigenschaft p erweitert werden. Der Code

for (var i in a) { if(typeof a[i]==='object') {a[i].p = p;} }

Wenn wir wissen, dass es immer ein Objekt ist, dann prüfen wir auf null

for (var i in a) { if(a[i] !== null) {a[i].p = p;} }

Wenn die Werte unterschiedliche Typen sind, dann darf kein Eintrag eine null sein, was ja aussagen würde, dass es ein Objekt ist.

Aber letztlich ist typeof sowieso mit Vorsicht zu geniessen und eigentlich nur zu empfehlen, um Fehlermeldung bei einem Wert der nicht deklariert ist zu vermeiden.

Struppi.

[Don P]

Hallo,

es geht darum dass null einzig und allein dazu da ist ein Objekt darzustellen - ein nicht vorhandenes Objekt.

Ansonsten hat dieser Wert keinen anderen Zweck. Deshalb ist der Typ von null ein 'object'. Für mich ist das logisch.

In gewisser Weise logisch, ja, aber nicht besonders sinvoll.

Denn es bedeutet, dass ich Variabeln die ein Objekt beinhalten können immer einen Wert vom Typ 'object' haben.

Das ist in einer eigentlich typfreien Programmiersprache doch unnötig. Mit dem gleichen Argument könnte man leere Parkplätze zu Autos erklären. Die sind auch nur dazu da, Autos aufzunehmen. Aber es sind eben nur leere Parkplätze, keine Autos.

Ich weiß nicht, für welchen Zweck du null einsetzen möchtest und was du mit den von dir vorgeschlagenen Typen machen willst.

Ist doch klar: Ich will vielleicht manchmal wissen, was in einer Variable gespeichert ist, und zwar direkt, ohne ein Auto zusätzlich fragen zu müssen, ob es nicht in Wirklichkeit nur ein Parklplatz ist.

Aber ich bin bisher mit dieser Konvention gut und ohne Probleme zu recht gekommen.

Ich auch, außer in Verbindung mit typeof. Wozu sollte man denn typeof überhaupt verwenden, wenn nicht um zu erfahren, mit was für einem Wert man es zu tun hat? Wenn die Auskunft 'null' wäre, hätte ich kein Problem zu erkennen, dass auch ein Objekt hinpasst. Wenn die Antwort jetzt 'object' lautet, weiß ich aber nicht, ob ich mit diesem "Objekt" arbeiten kann. Also was nützt das?

Nehmen wir z.B. ein Array a mit i Elementen, und jedes Element a[i], das ein Objekt ist...
Wenn die Werte unterschiedliche Typen sind, dann darf kein Eintrag eine null sein, was ja aussagen würde, dass es ein Objekt ist.

*Grummel*, nein! Es würde nur aussagen, dass es *vielleicht* ein Objekt ist. Wenn die Werte sonstwo zusammengklaubt wurden, ist vielleicht ein Objekt zur Zeit nicht existent und der Wert null, aber das könnte mir typeof doch direkt sagen ohne um den Brei herumzureden: "'object', hehe, aber frag' mich bloß nicht, ob's auch stimmt".

Aber letztlich ist typeof sowieso mit Vorsicht zu geniessen

Wieso eigentlich? Klar: Weil es zum Teil unbrauchbare Ergebnisse liefert, wie z.B. typeof null === 'object' :P

Gruß, Don P

[Struppi]

Das ist in einer eigentlich typfreien Programmiersprache doch unnötig. Mit dem gleichen Argument könnte man leere Parkplätze zu Autos erklären. Die sind auch nur dazu da, Autos aufzunehmen. Aber es sind eben nur leere Parkplätze, keine Autos.

Das ist die Frage, ist typeof wirklich dazu da, zu ermitteln ob es ein Auto ist oder nicht eher ob der Wert den Platz für ein Auto bereit hält? Vielleicht ist die Wahl des Ausdrucks unglücklich gewählt.

Ich weiß nicht, für welchen Zweck du null einsetzen möchtest und was du mit den von dir vorgeschlagenen Typen machen willst.

Ist doch klar: Ich will vielleicht manchmal wissen, was in einer Variable gespeichert ist, und zwar direkt, ohne ein Auto zusätzlich fragen zu müssen, ob es nicht in Wirklichkeit nur ein Parklplatz ist.

Dann musst du Fragen ob es ein instanceof einem Auto ist

Aber ich bin bisher mit dieser Konvention gut und ohne Probleme zu recht gekommen.

Ich auch, außer in Verbindung mit typeof. Wozu sollte man denn typeof überhaupt verwenden, wenn nicht um zu erfahren, mit was für einem Wert man es zu tun hat? Wenn die Auskunft 'null' wäre, hätte ich kein Problem zu erkennen, dass auch ein Objekt hinpasst. Wenn die Antwort jetzt 'object' lautet, weiß ich aber nicht, ob ich mit diesem "Objekt" arbeiten kann. Also was nützt das?

Naja, du weißt, das eigentlich ein Objekt erwartet wurde. Das ist die einzige Information die dir null gibt, ansonsten könntest du auch false, 0 oder einen Leerstring benutzen, um anzuzeigen das etwas nicht vorhanden ist.

Nehmen wir z.B. ein Array a mit i Elementen, und jedes Element a[i], das ein Objekt ist...
Wenn die Werte unterschiedliche Typen sind, dann darf kein Eintrag eine null sein, was ja aussagen würde, dass es ein Objekt ist.

*Grummel*, nein! Es würde nur aussagen, dass es *vielleicht* ein Objekt ist. Wenn die Werte sonstwo zusammengklaubt wurden, ist vielleicht ein Objekt zur Zeit nicht existent und der Wert null, aber das könnte mir typeof doch direkt sagen ohne um den Brei herumzureden: "'object', hehe, aber frag' mich bloß nicht, ob's auch stimmt".

Tut es ja auch nicht, es sagt dir, dass an dieser Stelle eigentlich ein Objekt stehen müßte, aber irgendwer oder irgendwas das vergeigt hat. Wenn du mehr wissen willst: alert(null instanceof Object)

Aber letztlich ist typeof sowieso mit Vorsicht zu geniessen

Wieso eigentlich? Klar: Weil es zum Teil unbrauchbare Ergebnisse liefert, wie z.B. typeof null === 'object' :P

Nein, weil es nur object, number, boolean, string, function und undefined gibt. Darüber hinaus aber anscheinend auch Browser, die das nicht richtig machen, wie Mathias behauptet, der auch nicht so ganz zufrieden mit null als Objekt zu sein scheint.

Struppi.

[Kai345]

[latex]Mae  govannen![/latex]

typeof benutzte ich eigentlich immer um rauzufinden, ob ein Wert definiert ist.

Ob etwas überhaupt definiert ist prüfe ich, wenn überhaupt nötig, mit if(sth!==undefined)...

Kann man nur dann sicher machen, wenn man garantiert nie und nimmer irgendwelche Fremd-Scripts einbindet, und auch die eigenen Scripts nicht für Andere zur Verfügung stellt.

Denn sonst kann es immer passieren, daß jemand mit wenig JS-Ahnung eine Variable namens undefined benutzt:

var undefined = true;

und schon klappt nichts mehr, wie es soll. Test auf undefined ist bad practice.

Entweder direkt if (!o) oder besser if typeof o != 'undefined'

Cü,

Kai