undefined als Wert einer Objekt-Eigenschaft erlaubt?

[LanX!]

Hi

Crockford behaupted in seinem O'Reilly Buch "JS the good parts" dass Objekte/Hashes kein undefined als Wert haben dürfen.

"An object is a container of properties, where a property has a name and a value. A property name can be any string, including the empty string. A property value can be any JavaScript value except for undefined."

Ich kann dass im FF nicht nachvollziehen, hat jmd ne Ahnung was gemeint sein könnte, gibt es JS Engines die da Probleme machen?

  
var h={i:undefined};  
for (x in h) alert(x+" : "+h[x]); //gibt "i : undefined" aus  

Grüße
  Rolf

[molily]

"An object is a container of properties, where a property has a name and a value. A property name can be any string, including the empty string. A property value can be any JavaScript value except for undefined."

Das ist falsch.

Ich kann dass im FF nicht nachvollziehen, hat jmd ne Ahnung was gemeint sein könnte, gibt es JS Engines die da Probleme machen?

Nein, ich wüsste nicht, wieso das Probleme machen sollte.

Es ist halt in der Praxis schwierig, mit undefined-Properties zu arbeiten, d.h. sie von tatsächlich nicht vorhandenen abzugrenzen.

var o = { p : undefined };  
  
o.p // ergibt undefined  
o.x // ergibt undefined  
  
if (o.p) // springt in den else-Block  
if (o.x) // springt in den else-Block  
  
typeof o.p // ergibt undefined  
typeof o.x // ergibt undefined  
  
"p" in o // ergibt true  
"x" in o // ergibt false

Absichtlich würde ich deshalb nicht mit undefined-Werten arbeiten. Wenn etwas gesetzt ist, aber keinen Wert hat, dann sollte man null verwenden.

Mathias

[LanX!]

Hi Matthias

Absichtlich würde ich deshalb nicht mit undefined-Werten arbeiten. Wenn etwas gesetzt ist, aber keinen Wert hat, dann sollte man null verwenden.

Inwiefern ist null besser? Nur weil du den Wert null statt undefined zurückbekommst?

Ich bin dieses Verhalten von Perl gewöhnt, dort prüft man mit "exists" in JS halt mit "in".

Mich stört die numification und stringification von undefined, aber da hilft null auch nur bedingt.

Grüße
  Rolf

[Beat]

Ich bin dieses Verhalten von Perl gewöhnt, dort prüft man mit "exists" in JS halt mit "in".

Für das Archiv!
Nein.
exists() prüft in Perl, ob ein Hashkey vorhanden ist, sagt aber nichts über den Zustand des Wertes aus.
Dafür gibt es defined(), welches auf den _Wert_ undef prüft.

mfg Beat

[LanX!]

Für das Archiv!
Nein.

Für das Archiv!
doch, es geht hier genau um das Verhalten von exists, dass du so schön beschrieben hast.

Wobei ich jetzt eher die hasOwnProperty-Methode vorziehen würde, weil "in" auch auf Vererbung prüft.

mfg
 Rolf

[Beat]

Für das Archiv!
doch, es geht hier genau um das Verhalten von exists, dass du so schön beschrieben hast.

Sorry, ich habe deine Aussage auf die falsche Zeile bezogen.
Ich ging immer noch von der Wertabfrage, nicht von der Eigenschaftsabfrage (äquivalen einem Hashkey) aus.

mfg Beat

[Cheatah]

Hi,

Zitat ergänzt, um ein Posting zu sparen:

Es ist halt in der Praxis schwierig, mit undefined-Properties zu arbeiten, d.h. sie von tatsächlich nicht vorhandenen abzugrenzen.

Ich tippe, genau darauf zielt die extrem ungünstige Formulierung ab. undefined "soll" (so verstehe ich das Timbre des Buchzitats) als "Eigenschaft ist nicht vorhanden" interpretiert werden, wodurch impliziert wird, dass es kein Wert einer vorhandenen Eigenschaft sein kann. Das macht die Sache nicht richtiger, erklärt aber vielleicht, was gemeint sein könnte bzw. was sich der Autor gedacht haben mag.

Inwiefern ist null besser?

null (NULL, Null)[1] ist vielerorts definiert als "kein Wert". Wenn man also diese Aussage treffen möchte - Eigenschaft existiert, besitzt jedoch keinen Wert - bietet es sich an, null zuzuweisen.

Cheatah

[1] Bisweilen auch None o.ä.

[LanX!]

hi

null (NULL, Null)[1] ist vielerorts definiert als "kein Wert". Wenn man also diese Aussage treffen möchte - Eigenschaft existiert, besitzt jedoch keinen Wert - bietet es sich an, null zuzuweisen.

null bietet sich IMHO nur an wenn man klar machen möchte dass es kein Wert von ist JS irgendwann selbst erzeugt hat, weil AFAIK unter keinen Umständen null zurückgegeben wird (wohl aber undefined)

Ich sehe "null" nur als Versuch aus Symmetriegründen ein "undefined" vom Typ object zu haben.

Das Verhalten von undefined ist parallel zu undef in Perl, bis auf die nervigen Einschränkungen die ich bereits gemacht habe in der Typumwandlung.

BTW: Die "ungünstige Formulierung des Autors" ist noch ungünstiger ins Deutsche übersetzt worden. Insgesamt bin ich von dem hingerotztem Büchlein eher enttäuscht.

cheers
   Rolf

[molily]

null bietet sich IMHO nur an wenn man klar machen möchte dass es kein Wert von ist JS irgendwann selbst erzeugt hat, weil AFAIK unter keinen Umständen null zurückgegeben wird (wohl aber undefined)

Sämtliche Core- und HTML-DOM-Methoden geben null zurück und manche nehmen null als Parameter entgegen. undefined kommt in den meisten eingebauten APIs nicht vor. Oder meinst du im ECMAScript-Core?

Mathias

[Struppi]

null bietet sich IMHO nur an wenn man klar machen möchte dass es kein Wert von ist JS irgendwann selbst erzeugt hat, weil AFAIK unter keinen Umständen null zurückgegeben wird (wohl aber undefined)

Sämtliche Core- und HTML-DOM-Methoden geben null zurück und manche nehmen null als Parameter entgegen. undefined kommt in den meisten eingebauten APIs nicht vor.

Das ist auch völlig logisch, da null das gegenteil eines definierten Objektes ist. undefined ist nur der Wert einer deklarierten Variabel oder Attribut ohne Zuweisung. Wenn eine Funktion sagt, dass sie ein Objekt zurückgibt, muss sich im Fehlerfall null zurück geben. Damit ist auch gewährleistet, dass typeof immer das Richtige ermittelt.

Struppi.

[LanX!]

Hi

Das ist auch völlig logisch, da null das gegenteil eines definierten Objektes ist. undefined ist nur der Wert einer deklarierten Variabel oder Attribut ohne Zuweisung. Wenn eine Funktion sagt, dass sie ein Objekt zurückgibt, muss sich im Fehlerfall null zurück geben. Damit ist auch gewährleistet, dass typeof immer das Richtige ermittelt.

Hmm, beim DOM macht das tatsächlich irgendwo Sinn, schließlich sind das ja nativ realisierte Funktionen des Browsers in statisch typisierten Sprachen - sprich meist C.

Die rufen sich ja zuweilen auch gegenseitig auf, da muss der Typ stimmen.

Bye
 rolf

[LanX!]

Sämtliche Core- und HTML-DOM-Methoden geben null zurück und manche nehmen null als Parameter entgegen. undefined kommt in den meisten eingebauten APIs nicht vor. Oder meinst du im ECMAScript-Core?

Also ich habs gelesen und ich weiß jetzt (zu meiner Schande?) keine JS -Core wo mir ein Rückgabewert von  null bekannt wäre, höchstens bei den Konstruktoren.

Gruß
  Rolf

[Tim Tepaße]

Also ich habs gelesen und ich weiß jetzt (zu meiner Schande?) keine JS -Core wo mir ein Rückgabewert von  null bekannt wäre, höchstens bei den Konstruktoren.

Ich hab ein einfaches ⌘F in ECMAScript 5 nach „return null“ gemacht und folgende gefunden:

• RegExp.prototype.exec wenn kein Treffer erzielt wurde.
• String.prototype.match wenn kein Treffer erzielt wurde.
• Date.prototype.toJSON wenn die das Datum symbolisierende Zahl nicht endlich, d.h. gleich ±Infinity ist.

[LanX!]

Danke Tim, das sind aber genau die Fälle in denen im Erfolgsfall Objekte returniert würden.

[molily]

Inwiefern ist null besser? Nur weil du den Wert null statt undefined zurückbekommst?

null wird üblicherweise verwendet, um eine Variable oder Eigenschaft mit einem Wert zu belegen, welcher »kein Wert« bedeutet. Z.B. als Default-Wert einer noch nicht sinnvoll gefüllten Eigenschaft oder als Wert für einen Parameter, den man leer lassen will (func("eins", null, "drei")).

Vorteil ist, dass man null einfach von nicht gesetzten Eigenschaften unterscheiden kann, ohne »in« oder »hasOwnProperty« verwenden zu müssen. Wenn man das nicht braucht oder man kein Problem mit »in«/»hasOwnProperty« hat, dann eignet sich undefined natürlich genauso. null ist halt eine Konvention, die es so auch in anderen Sprachen gibt.

Mich stört die numification und stringification von undefined, aber da hilft null auch nur bedingt.

Was heißt Numification/Stringification?

Mathias

[LanX!]

Hi

Vorteil ist, dass man null einfach von nicht gesetzten Eigenschaften unterscheiden kann, ohne »in« oder »hasOwnProperty« verwenden zu müssen.

ja und wie machst du das?

Was heißt Numification/Stringification?

repl> ""+undefined
"undefined"
repl> 0+undefined
NaN
repl> ""+null
"null"
repl> 0+null
0

Grüße
 Rolf

[molily]

Vorteil ist, dass man null einfach von nicht gesetzten Eigenschaften unterscheiden kann, ohne »in« oder »hasOwnProperty« verwenden zu müssen.

ja und wie machst du das?

o.p === null

Mathias

[Struppi]

Inwiefern ist null besser? Nur weil du den Wert null statt undefined zurückbekommst?

null wird üblicherweise verwendet, um eine Variable oder Eigenschaft mit einem Wert zu belegen, welcher »kein Wert« bedeutet.

Ich halte null eher für den Wert eines undefinierten Objekt, undefined wäre aus meiner Sicht genau der richtige Wert, um einen Wert einer nicht genauer typisierten Variabel oder Eigenschaft zu zuweisen. Das ist auch genau das was passiert, wenn man eine Variabel deklariert, ohne ihr einen Wert zu geben.

null ist der unwahre Wert eines Objektes.

Struppi.

[EKKi]

Mahlzeit LanX!,

Absichtlich würde ich deshalb nicht mit undefined-Werten arbeiten. Wenn etwas gesetzt ist, aber keinen Wert hat, dann sollte man null verwenden.

Inwiefern ist null besser? Nur weil du den Wert null statt undefined zurückbekommst?

"null" bedeutet mehr oder weniger "kein Wert".
"undefined" bedeutet mehr oder weniger "nicht definiert".

Was trifft eher zu, wenn es eine bestimmte Eigenschaft zwar gibt bzw. geben soll, diese aber zu bestimmten Zeitpunkten keinen Wert haben soll?

MfG,
EKKi

[LanX!]

Mahlzeit!

Was trifft eher zu, wenn es eine bestimmte Eigenschaft zwar gibt bzw. geben soll, diese aber zu bestimmten Zeitpunkten keinen Wert haben soll?

siehe Codebeispiel in

http://forum.de.selfhtml.org/?t=199637&m=1344666

Bye
  Rolf

[Don P]

Hallo,

var o = { p : undefined };

"p" in o // ergibt true
"x" in o // ergibt false

>   
> Absichtlich würde ich deshalb nicht mit undefined-Werten arbeiten.  
  
Ich schon. Gerade die Tatsache `("p" in o && !o["p"]) === true`{:.language-javascript} nütze ich manchmal aus:  
Es werden Eigenschaften/Methoden von o angelegt, die manchmal bewußt mit undefined initialisiert sind.  
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).  
Dazu werden etwa mit  
`for (var p in o) { myObj = o[p]||d[p]; }`{:.language-javascript}  
die Eigenschaften durchlaufen und zugeordnet. Natürlich würde das auch mit null funktionieren...  
  

> Wenn etwas gesetzt ist, aber keinen Wert hat, dann sollte man null verwenden.  

...aber null steht ja üblicherweise für ein nicht vorhandenes \*Objekt\*.  
undefined dagegen ist allgemeiner, und steht für irgend etwas nicht gesetztes.  
  
Gruß, Don P  

[molily]

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

[LanX!]

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.

Ich kenne in JS-Core keine Funktion/Methode die null zurückgibt.

Was die Leute eher verwenden hängt davon ab wo sie verstärkt herkommen, Java-Leute tendieren zu null und scheinen bei Frameworks zu dominieren.

Vielleicht auch weil DOM-Funktionen halt in C artigen Sprachen geschrieben werden.

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.

Andererseits ist es das einzige Beispiel eines Typs object dass false ist.
Jeder andere Datentyp hat eine solchen null-instanz, also 0,"" und false, das spricht sehr für symmetriegründe.

Und das C/Java Leute den type von null als Fehler ansehen, kann auch bedeuten, dass sie mit Perls undef einfach nicht umgehen können.

Aber ich glaube die Wahrheit ist viel einfacher, beim Zusammenmanschen von Perl, Self und Java-features hat sich Brendan Eich nicht entscheiden können, und doppelt gemoppelt für gut befunden. :)

Bis denne
  Rolf

PS: Aber gut wer weiß, nur weil ich's mir nicht vorstellen kann, bedeutet es nicht dass ich nicht irgendwann null nutzen werde, um bewusstes Leer von automatischem Leer zu unterscheiden.

[Struppi]

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

Wieso? Wenn null als Object definiert ist, dann ist es logischerweise auch der Platzhalter für ein Object.

Daher sehe ich auch nicht, warum es ein Fehler sein soll dass typeof null object ist.

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

Ja, und zwar immer dann wenn die Defintion sagt, dass die Funktion ein Objekt zurückgibt. Wenn dieses Objekt nicht erzeugt werden kann (oder nicht gefunden) wird null zurückgegeben.

Dagegen ist "kein Wert" undefined

Struppi.

[molily]

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

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.

»The ECMAScript language types are Undefined, Null, Boolean, String, Number, and Object.«
http://ecma262-5.com/ELS5_HTML.htm#Section_8

»A primitive value is a member of one of the following built-in types: Undefined, Null, Boolean, Number, and String«
http://ecma262-5.com/ELS5_HTML.htm#Section_4.2

»4.3.11 null value
primitive value that represents the intentional absence of any object value.

4.3.12   Null type
type whose sole value is the null value.«
http://ecma262-5.com/ELS5_HTML.htm#Section_4.3.11 f.

Gut, da steht »object value«, aber faktisch hat das keine Auswirkung, denn eine Variable/Eigenschaft hat in JavaScript keinen festen Typ.

Ja, und zwar immer dann wenn die Defintion sagt, dass die Funktion ein Objekt zurückgibt. Wenn dieses Objekt nicht erzeugt werden kann (oder nicht gefunden) wird null zurückgegeben.

Ja, das stimmt. Das DOM gibt m.W. nie null zurück, wenn ein Primitive erwartet wird. Die Erklärung dafür ist: Das DOM ist auf statisch getypte Sprachen wie Java ausgelegt. Da kann m.W. eine Methode immer nur einen Typ zurückgeben, und wenn es ein Object zurückgibt, dann kann es nur null zurückgeben, wenn es »kein Object« zurückgeben will. In ActionScript, einem statisch getypten ECMAScript-Ableger, ist es ähnlich (es sei denn, man verwendet als Typ »*«).

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.

Dagegen ist "kein Wert" undefined

undefined ist, wie du auch sagst, erst mal der Wert einer Variable, die noch keinen Wert bekommen hat. Ferner ist undefined ist der Rückgabewert von [[GetProperty]], wenn ein Objekt die angefragte Eigenschaft nicht besitzt.

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?");

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.

Mathias

[LanX!]

Hi Matthias

lass uns mal ein gängiges Idiom aus  Perl (<5.10) als konkretes Beispiel nehmen, ein Konstruktor F der positionelle Parameter¹ bekommt, die wenn fehlend defaulted werden sollen.

  
repl> function F (a,b,c) {  
   this.a= (a !== undefined) ? a :"A";  
   this.b= (b !== undefined) ? b :"B";  
   this.c= (c !== undefined) ? c :"C";  
}  
repl> x = new F()  
[object Object] — {a: "A", b: "B", c: "C"}  
repl> x = new F("a")  
[object Object] — {a: "a", b: "B", c: "C"}  
repl> x = new F(null)  
[object Object] — {a: null, b: "B", c: "C"}  
repl> x = new F("a",undefined,"c")  
[object Object] — {a: "a", b: "B", c: "c"}  

Übergebe ich undefined oder fehlt eine Angabe wird der Wert mit einem Default ersetzt.

Um nur a und c zu übergeben brauche ich undefined für b!

Ich könnte jetzt zwar != statt !== schreiben um auch null zu defaulten, dann hätte ich aber keine Möglichkeit mehr null als "falsches" Objekt durchzureichen.

»»4.3.11 null value
»»primitive value that represents the intentional absence of any object value.

4.3.12   Null type
type whose sole value is the null value.«
http://ecma262-5.com/ELS5_HTML.htm#Section_4.3.11 f.

Gut, da steht »object value«, aber faktisch hat das keine Auswirkung, denn eine Variable/Eigenschaft hat in JavaScript keinen festen Typ.

Man hat so aber, aus Symetriegründen, immer einen "falschen" Wert für eine Typklasse.

wenn ich z.B. match aufrufe kann ich sichergehen dass alle Ergebnisse typeof "object" sind, auch wenn null zurückgegeben wird.

JS macht die Typprüfung nicht implizit aber vielleicht braucht man sie irgendwann explizit. Oder der Aufruf erfolgt aus ner typisierten Sprache wie Java?

Die "Praxis" null als gewolltes "undefined" zu nutzen hat sich vielleicht eingebürgert, dahingehend designt und vorgesehen wurde es aber nicht.

Ciao
  Rolf

¹) ab mehr als 3 Argumenten sollte man lieber ein Hash mit benannten keys übergeben ... also F({a:"a",c:"c"})

[molily]

JS macht die Typprüfung nicht implizit aber vielleicht braucht man sie irgendwann explizit. Oder der Aufruf erfolgt aus ner typisierten Sprache wie Java?

Die "Praxis" null als gewolltes "undefined" zu nutzen hat sich vielleicht eingebürgert, dahingehend designt und vorgesehen wurde es aber nicht.

Wie gesagt, ich bezweifle nicht, dass hier offensichtlich Java als streng typisierte Sprache Pate gestanden hat und die Core-API dieser nachempfunden wurde. In diesen Sprachen macht null als Gegensatz zu undefined Sinn. Gleichzeitig verletzt ECMAScript die Regel, dass eine Methode immer einen bestimmten Typ zurückgibt, mit undefined ständig. Das DOM ist da konsequent, z.B. getAttribute gibt einen leeren String zurück, wenn kein solches Attribut existiert, weil der Rückgabewert eben immer ein String ist. Das halte ich für Quatsch in Sprachen wie ECMAScript und würde keine JS-API so entwerfen. Aber gut, das DOM ist eben programmiersprachenunabhängig und nutzt daher den kleinsten gemeinsamen Nenner.

ECMAScript ist eine funktionale, dynamisch getypte Sprache, die auf komplett auf mutable objects, Prototypen und funktionalem Scope basiert. Trotzdem hat sie unzählige Einsprengsel, die aus streng getypten, konventionell klassenbasierten Sprachen stammen. Ich weiß nicht, wie Perl da tickt, aber in Python und Ruby, die hinsichtlich Typen mit ECMAScript wohl eher zu vergleichen sind als Java, gibt es m.W. keine Unterscheidung zwischen null und undefined. In Python gibt es None, in Ruby nil. In ECMAScript halte ich die Aufspaltung in undefined und null für ziemlich willkürlich und eben nur historisch erklärbar. - Genauso wie z.B. der new-Operator, der eine Analogie zu klassenbasierten Sprachen ist und im funktionalen/prototypischen JavaScript überhaupt nicht gebraucht wird bzw. von dem Leute wie Crockford abraten, weil er die Natur der Sprache mehr verhüllt als offenlegt.

Die Frage mit den optionalen Parametern stellt sich in einer Sprache wie ECMAScript m.E. nicht. Ich finde es schwierig, da aussagekräftige Beispiele zu finden. Es ist gang und gäbe, dass Methoden überladen werden, sodass optionale Parameter einfach weggelassen werden und die Parameteranzahl variabel ist. JavaScript-APIs werden so implementiert, dass gemäß dem Paradigma der schwachen Typisierung aus dem Wert immer etwas (hoffentlich) sinnvolles gemacht wird bzw. er ansonsten einfach verworfen wird. Wenn ein truthy-Wert benötigt wird, dann ist es egal, ob "", 0, false, undefined oder null hereinkommt. Wenn z.B. ein String erwartet wird, dann werden auch alle anderen Typen akzeptiert und entsprechend gecastet.

Mathias

[LanX!]

Hi

Ich weiß nicht, wie Perl da tickt, aber in Python und Ruby, die hinsichtlich Typen mit ECMAScript wohl eher zu vergleichen sind als Java, gibt es m.W. keine Unterscheidung zwischen null und undefined. In Python gibt es None, in Ruby nil.

In Perl gibts nur undef, dass sich so ziemlich so wie undefined in JS verhält, mit der Ausnahme des Typecasting.

repl> undefined+0  
NaN  
repl> undefined+""  
"undefined"  

  DB<1> $x=undef  
  
  DB<2> print $x."666"  
666  
  DB<3> print $x+666  
666  

In Python hingegen gibts AFAIK keine undefinierten Variablen, weil eine Deklaration immer auch eine Initialisierung beinhaltet.

In ECMAScript halte ich die Aufspaltung in undefined und null für ziemlich willkürlich und eben nur historisch erklärbar. -

D'accord. Aber am willkürlichsten ist wenn Java-Programmierer der Sprache ihre Muster aufzwingen.

Genauso wie z.B. der new-Operator, der eine Analogie zu klassenbasierten Sprachen ist und im funktionalen/prototypischen JavaScript überhaupt nicht gebraucht wird bzw. von dem Leute wie Crockford abraten, weil er die Natur der Sprache mehr verhüllt als offenlegt.

Naja Crockford macht peinliche Fehler in seinem Buch und ist auch launenhaft in seinen Ansichten...der Mann kommt von Java und man merkt seinen Reden an dass er früher mit Scripting auf dem Kriegsfuss stand und m.E. immer noch steht. Aber er verkauft sich gut.

In allen OOP Sprachen die ich kenne gibts einen Container für Methoden und (mindestens) einen Konstruktor der meist new heist.

In JS ist der Konstruktor ne spezielle Funktion und die Methoden werden im Prototype dieser Funktion gehalten.

new leitet ein neues Object von Konstruktor ab, Crockfords "beget" oder "create" Methode oder wie er es gerade nennt aber von einem Objekt dass er zum Prototyp macht und vereinfacht dabei  den Konstruktor.

Das hat beides seine Vor und Nachteile, je nachdem was einem gerade wichtiger ist, ein variabler Konstruktor oder variabler Methodencontainer.

Sein Ansatz ist zugegeben intuitiver, weil er Vererbungsketten vereinfacht, aber beide Aspekte zu beachten wäre m.E. besser.

Tschau
  Rolf

[Struppi]

Gleichzeitig verletzt ECMAScript die Regel, dass eine Methode immer einen bestimmten Typ zurückgibt, mit undefined ständig. Das DOM ist da konsequent, z.B. getAttribute gibt einen leeren String zurück, wenn kein solches Attribut existiert, weil der Rückgabewert eben immer ein String ist.

In welchem Browser?
javascript:alert(document.forms[0].getAttribute('name'));

gibt bei mir im Firefox null (hier im Forum)

In ECMAScript halte ich die Aufspaltung in undefined und null für ziemlich willkürlich und eben nur historisch erklärbar.

Das sehe ich auch so.

Wenn ein truthy-Wert benötigt wird, dann ist es egal, ob "", 0, false, undefined oder null hereinkommt. Wenn z.B. ein String erwartet wird, dann werden auch alle anderen Typen akzeptiert und entsprechend gecastet.

Und wie ich schon sagte, im Prinzip könnte man, um z.b. zwischen einem Leerstring oder der Zahl null zu unterschieden, auch false oder undefined benutzen.

Struppi.

[Struppi]

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

[LanX!]

Hi

kurz eingeworfen:

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

nein IIRC "number", "string" und "boolean" (kleingeschrieben!) sind Pseudoobjekte.

Es sind einfache Datentypen die bei Bedarf als Objekte benutzt werden können, indem man Methoden der entsprechenden Objekte auf sie aufruft.

ich stelle es mir wie ein implizites bless in Perl vor, ungefähr so wie autobox funtioniert.

Tschau
  Rolf

[Struppi]

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

nein IIRC "number", "string" und "boolean" (kleingeschrieben!) sind Pseudoobjekte.

Und Number, String und Boolean sind Objekte (Großgeschrieben) bzw. Konstruktorfunktionen, die entsprechende Objekte erzeugen.

Es sind einfache Datentypen die bei Bedarf als Objekte benutzt werden können, indem man Methoden der entsprechenden Objekte auf sie aufruft.

Nein, umgekehrt. Es sind Objekte, die - wegen mir - bei Bedarf, als primitive Datentypen verwendet werden können und entsprechend umgewandelt werden.

Wie gesagt, es geht wie in dem Beispiel von Mathias um dir Rückgabe von prompt(), das ist ein String oder null, was insofern durchaus logisch ist, das ein String eben auch ein Objekt ist.

Struppi.

[LanX!]

Nein, umgekehrt. Es sind Objekte, die - wegen mir - bei Bedarf, als primitive Datentypen verwendet werden können und entsprechend umgewandelt werden.

Das macht keine Sinn, du kannst den typeof überprüfen von a="str" und a=new String("str"). Trotzdem kannst du Methoden des "Wrapperobjektes" (Zitat MDC) auf den primitiven Typ aufrufen (nicht alle haben einen Effekt, weil das temporäre Objekt wieder zerstört wird)

Der primitive Typ wird sich aber sonst immer als solcher aufführen.

[LanX!]

Wie gesagt, es geht wie in dem Beispiel von Mathias um dir Rückgabe von prompt(), das ist ein String oder null, was insofern durchaus logisch ist, das ein String eben auch ein Objekt ist.

da hätte er recht wenn's so wäre, typeof des results ist "string" nicht "object", allerding erhalte ich im FF einen Leerstring bei fehlender Eingabe.

MDC ist dahingehend inkonsistent:

https://developer.mozilla.org/en/window.prompt

bye
  rolf

[LanX!]

MDC ist dahingehend inkonsistent:

https://developer.mozilla.org/en/window.prompt

ahh jetzt kapiere ich, wenn man auf "Abbrechen" klickt wird null zurückgegeben.

Also null ist natürlich schon mal besser als Leerstring.

... hmm...

Also mit typeof hat das ganze wenig zu tun, warum sollte die Rückgabe von "Abbrechen" vom Typ String sein?

Und was wäre die richtige Rückgabe, wenn es einen Knopf "Später nochmal Fragen" gäbe???

Die Entscheidung für Null ist doch da eher Konsequent, weil man bei mehreren Knöpfen sinnvollerweise ein Objekt zurückgeben sollte.

Gruß
  Rolf

BTW: "DOM Level 0. Not part of any standard. "

[LanX!]

hi

Dazu werden etwa mit
for (var p in o) { myObj = o[p]||d[p]; }
die Eigenschaften durchlaufen und zugeordnet. Natürlich würde das auch mit null funktionieren...

und mit 0 und '' und false und allem was sonst noch "falsch" ist.

ganz schön gefährlich, oder?

deswegen hat Perl den // Operator für "defined-or" eingeführt.

Grüße
  Rolf

PS: so oder?
for (var p in o) { myObj = o[p]||d[p]; }

[LanX!]

PS: so oder?
for (var p in o) { myObj = o[p]||d[p]; }

ähm
for (var p in o) { myObj[p] = o[p]||d[p]; }

[Don P]

Hallo,

ähm
for (var p in o) { myObj[p] = o[p]||d[p]; }

ähm ja, klar.

Gruß, Don P

[Struppi]

Crockford behaupted in seinem O'Reilly Buch "JS the good parts" dass Objekte/Hashes kein undefined als Wert haben dürfen.

"An object is a container of properties, where a property has a name and a value. A property name can be any string, including the empty string. A property value can be any JavaScript value except for undefined."

Ich bin der Meinung es ist ein (Druck?)Fehler und muss heißen:

A property *name* can be any JavaScript value except for undefined.

Dann macht der Satz Sinn, ansonsten nicht.

Struppi.

[Kai345]

[latex]Mae  govannen![/latex]

Ich bin der Meinung es ist ein (Druck?)Fehler und muss heißen:

A property *name* can be any JavaScript value except for undefined.

Ist allerdings nicht als solcher aufgeführt Errata

Cü,

Kai

[Kai345]

[latex]Mae  govannen![/latex]

Ich bin der Meinung es ist ein (Druck?)Fehler und muss heißen:

A property *name* can be any JavaScript value except for undefined.

Ist allerdings nicht als solcher aufgeführt Errata

Ich vermute etwas völlig anderes: Das Buch heißt ja »Good Parts« und ist eben nicht dazu da, Javascript im Allgemeinen zu definieren. Crockford sieht es eben nicht als »good part« an, wenn als property value undefined verwendet wird. Daher ist aus *dieser* Sicht die Aussage richtig.

Cü,

Kai

[Struppi]

Ich vermute etwas völlig anderes: Das Buch heißt ja »Good Parts« und ist eben nicht dazu da, Javascript im Allgemeinen zu definieren. Crockford sieht es eben nicht als »good part« an, wenn als property value undefined verwendet wird. Daher ist aus *dieser* Sicht die Aussage richtig.

Ich vermute auch dass du recht hast.

Aber das wäre dann völlig willkürlich, da ein undefinierter Wert Sinn macht, wenn es nicht sicher ist, welcher Typ ein zukünftiger Wert haben sollte. Wobei das aber wiederum tunlichst vermieden werden sollte.

Struppi.

[Kai345]

[latex]Mae  govannen![/latex]

Ich vermute etwas völlig anderes: Das Buch heißt ja »Good Parts« und ist eben nicht dazu da, Javascript im Allgemeinen zu definieren. Crockford sieht es eben nicht als »good part« an, wenn als property value undefined verwendet wird. Daher ist aus *dieser* Sicht die Aussage richtig.

Ich vermute auch dass du recht hast.

Aber das wäre dann völlig willkürlich, da ein undefinierter Wert Sinn macht, wenn es nicht sicher ist, welcher Typ ein zukünftiger Wert haben sollte. Wobei das aber wiederum tunlichst vermieden werden sollte.

Douglas Crockford ist in manchen Dingen willkürlich. Sieht man besonders gut bei Verwendung von jsLint, wo bestimmte Stil-Schreibweisen, die ihm nicht passen, als Fehler gewertet werden. Glühkerzenweise kann man die meisten Optionen entsprechend selber bestimmen.

Cü,

Kai

[LanX!]

Hi

Ich bin der Meinung es ist ein (Druck?)Fehler und muss heißen:

A property *name* can be any JavaScript value except for undefined.

Dann macht der Satz Sinn, ansonsten nicht.

wäre auch dann falsch,  wie in Perl sind nur Strings als Keys erlaubt!

Tschau
 Rolf

[Struppi]

Ich bin der Meinung es ist ein (Druck?)Fehler und muss heißen:

A property *name* can be any JavaScript value except for undefined.

Dann macht der Satz Sinn, ansonsten nicht.

wäre auch dann falsch,  wie in Perl sind nur Strings als Keys erlaubt!

Da aber jedes Objekt eine toString() Methode hat, ist dies egal. Es wird auf jeden Fall ein Schlüssel erzeugt, der dann aber, wie du richtig sagst, im Endeffekt ein String ist.

Struppi.

[LanX!]

Hi

Da aber jedes Objekt eine toString() Methode hat, ist dies egal. Es wird auf jeden Fall ein Schlüssel erzeugt, der dann aber, wie du richtig sagst, im Endeffekt ein String ist.

Jein, im Gegensatz zu Perl kommt dann nicht immer ein anderer String mit einer kryptischen Speicheradresse¹ raus, wenn man eine Objectreferenz als Key benutzt, sondern verschiedene Objekte können/würden in JS den gleichen String erzeugen.

Tschau
  Rolf

1. und selbst hier muss man aufpassen.

[Struppi]

Da aber jedes Objekt eine toString() Methode hat, ist dies egal. Es wird auf jeden Fall ein Schlüssel erzeugt, der dann aber, wie du richtig sagst, im Endeffekt ein String ist.

Jein, im Gegensatz zu Perl kommt dann nicht immer ein anderer String mit einer kryptischen Speicheradresse¹ raus, wenn man eine Objectreferenz als Key benutzt, sondern verschiedene Objekte können/würden in JS den gleichen String erzeugen.

Ja genau, weil die toString() Methode intern so umgesetzt ist.

Struppi.

[LanX!]

Hi

Ja genau, weil die toString() Methode intern so umgesetzt ist.

Ja aber in JS hast du IMHO keine Chance, jedem Objekt einen unverwechselbare String als ID zuzuweisen, egal wie du toString() überschreibst.

bye
 rolf

[Struppi]

Ja genau, weil die toString() Methode intern so umgesetzt ist.

Ja aber in JS hast du IMHO keine Chance, jedem Objekt einen unverwechselbare String als ID zuzuweisen, egal wie du toString() überschreibst.

Das hab' ich auch nie gesagt. Aber theoretisch ist das möglich:

Object.prototype.toString = function() {  
    if(!Object._ID_) Object._ID_ = 1;  
    if(!this._ID_) this._ID_ = Object._ID_++;  
    return 'Object #' + this._ID_;  
};  

und damit könnte man Objekte als Schlüssel angeben:

var o1 = {};  
var o2 = {};  
var x = {};  
x[o1] = 'o1',  
x[o2] = 'o2'  
for(var a in x) alert(a);

Aber das macht keinen Sinn.

Zumal ich mittlerweile eher glaube, dass die These von Kai zutrifft und es nur um die "good parts" ging.

Meine anfänglich getroffene Aussage ist also falsch, auch deswegen, weil der Schlüssel immer in eine Zeichenkette umgewandelt wird.

Struppi.

[LanX!]

Hi

Das hab' ich auch nie gesagt. Aber theoretisch ist das möglich:

da bin ich skeptisch...

Zumal ich mittlerweile eher glaube, dass die These von Kai zutrifft und es nur um die "good parts" ging.

Glaub ich nicht, erstens ist das im Kontext nicht zu erkennen und zwotens ist das Buch ist voller weiterer schluderiger Aussagen.

Kein Ruhmesblatt.

Gruß
  Rolf

[LanX!]

Hi

Das hab' ich auch nie gesagt. Aber theoretisch ist das möglich:

da bin ich skeptisch...

Spezifischer: du erzeugst die ID erst beim toString, nicht bei der Objektkonstruktion (und hast keinen Einfluss auf die Destruktion), das könnte Seiteneffekte haben.

Allerdings sollte dein Ansatz funktionieren hätte er einen Vorteil gegenüber Perl, die Rückabbildung von String auf Objekt könnte gewährleistet werden. :)

Tschau
  Rolf

[Kai345]

[latex]Mae  govannen![/latex]

Zumal ich mittlerweile eher glaube, dass die These von Kai zutrifft und es nur um die "good parts" ging.

Glaub ich nicht, erstens ist das im Kontext nicht zu erkennen und zwotens ist das Buch ist voller weiterer schluderiger Aussagen.

Es ist für mich die einzig einleuchtende Erklärung.

Druckfehler --> wäre in Errata
Fehler von DC --> dazu kennt er JS eigentlich zu gut und falls doch wäre es trotzdem längst in Errata. Das Buch ist ja so neu auch wieder nicht, daß da noch niemand drüber gestolpert wäre.

Daher bleibt nur, daß DC undefined als "bad part" ansieht und daher sagt, daß undefined als property value im Kontext der "good parts" nicht vorkommen darf. Ich schätze, gleiches gilt auch für andere von dir kritisierte Aussagen.

Cü,

Kai

[LanX!]

Hi

Daher bleibt nur, daß DC undefined als "bad part" ansieht und daher
sagt, daß undefined als property value im Kontext der "good parts" nicht vorkommen darf. Ich schätze, gleiches gilt auch für andere von dir kritisierte

es gibt 3 Anhänge wo er "Schön", "Furchtbar" und "Schlecht" auflistet, undefined wird nicht erwähnt.

Du sprichst in heilig.

Fehler von DC --> dazu kennt er JS eigentlich zu gut und falls doch wäre es trotzdem längst in Errata.

Wieviele Leute nehmen JS ernst und kennen sich wirklich aus?

Das Buch ist ja so neu auch wieder nicht, daß da noch niemand drüber gestolpert wäre.

Sollte man meinen, ich bin ehrlicherweise auch ziemlich entäuscht über dieses zusammengeflickte Buch. Man muss sich die Infos selbst zusammensuchen und vieles noch mal extra gegenchecken.

Man Vergleiche nur Umfang, Aufbau und Qualität von Conways "Perl Best Practices"!

Naja, ich stelle bald ne Review online.

Tschau
  Rolf

[at]

Hallo.

Du sprichst in heilig.

Und in was sprichst du?
MfG, at

[LanX!]

Und in was sprichst du?

a a ser lustig ...

[ChrisB]

Hi,

"An object is a container of properties, where a property has a name and a value. A property name can be any string, including the empty string. A property value can be any JavaScript value except for undefined."

Ich bin der Meinung es ist ein (Druck?)Fehler und muss heißen:

A property *name* can be any JavaScript value except for undefined.

Dann macht der Satz Sinn, ansonsten nicht.

Ja, aber auf property names geht ja schon der Satz davor ein ...

MfG ChrisB