Boolean-Objekt

[dedlfix]

Hi!

Da im Wiki grad jemand so nett war, das Kapitel zum Boolean-Objekt einzuarbeiten, stellte sich für mich die Frage: Welche praktischen Anwendungsfälle kann man damit lösen, die sich nicht allein durch den Gebrauch der beiden "primitiven Werte" true und false erledigen lassen? Es geht mir auch darum, (Ideen für) Anwendungsbeispiele zu bekommen, die nicht so "an den Haaren herbeigezogen" aussehen.

Lo!

[Struppi]

Da im Wiki grad jemand so nett war, das Kapitel zum Boolean-Objekt einzuarbeiten, stellte sich für mich die Frage: Welche praktischen Anwendungsfälle kann man damit lösen, die sich nicht allein durch den Gebrauch der beiden "primitiven Werte" true und false erledigen lassen? Es geht mir auch darum, (Ideen für) Anwendungsbeispiele zu bekommen, die nicht so "an den Haaren herbeigezogen" aussehen.

Ein praktisches Beispiel dürfte schwer sein. Der einzige wirkliche Unterschied liegt darin, dass typeof ein anderes Ergebnis bringt.

var b = true;  
alert(typeof b); // boolean  
b = new Boolean(true);  
alert(typeof b); // object

Damit könnte b z.b. als Parameter verwendet werden, in einer Funktion die ein Objekt erwartet.

var b1 = true;  
var b2 = new Boolean(true);  
var b3 = new Boolean(false);  
f(b1); // p ist kein objekt  
f(b2); // ok  
f(b3); // p ist false  
  
function f(p) {  
	if(typeof p != 'object') return alert('p ist kein objekt');  
	if(p == false) return alert('p ist false');  
	alert('ok');  
}  

Wirklich sinnvoll ist es zwar nicht, aber damit liessen sich in der Funktion mehr Fälle unterscheiden, als p == null und p != null

Struppi.

[dedlfix]

Hi!

Ein praktisches Beispiel dürfte schwer sein. Der einzige wirkliche Unterschied liegt darin, dass typeof ein anderes Ergebnis bringt.

Danke erstmal für deine Antwort. Zumindest dieser Unterschied scheint mir Wert, in das Wiki eingearbeitet zu werden.

Mich würde noch interessieren, warum du jenen Satz streichenswert fandest. Er hat sicher nicht direkt was mit dem booleschen Objekt zu tun, sondern eher was allgemeines mit Variablen. Da aber <http://de.selfhtml.org/javascript/objekte/boolean.htm@title=die 8.x was von Konstanten schrub>, was ich als technisch falsch empfand, entstand zumindest dieser Satz als Ersatz.

Lo!

[Struppi]

Ein praktisches Beispiel dürfte schwer sein. Der einzige wirkliche Unterschied liegt darin, dass typeof ein anderes Ergebnis bringt.

Danke erstmal für deine Antwort. Zumindest dieser Unterschied scheint mir Wert, in das Wiki eingearbeitet zu werden.

Mich würde noch interessieren, warum du jenen Satz streichenswert fandest. Er hat sicher nicht direkt was mit dem booleschen Objekt zu tun, sondern eher was allgemeines mit Variablen. Da aber <http://de.selfhtml.org/javascript/objekte/boolean.htm@title=die 8.x was von Konstanten schrub>, was ich als technisch falsch empfand, entstand zumindest dieser Satz als Ersatz.

Der Satz:

Wenn Sie einer Variablen ein boolesches Objekt zugewiesen haben, so können Sie ihren Inhalt nur ändern, indem Sie ihr ein neues boolesches Objekt zuweisen.

Naja, weil es nicht wirklich stimmt.

Die Variabel kannst beliebig ändern, nur den Wert des Objektes nicht mehr. Das halte ich aber für nicht erwähnenswert, da das bei jedem Objekt so ist. Du kannst Eigenschaften und Methoden ändern, aber auf den Wert eines Objektes an sich, hast du in JS ja keinen Zugriff.

Struppi.

[dedlfix]

Hi!

Die Variabel kannst beliebig ändern, nur den Wert des Objektes nicht mehr. Das halte ich aber für nicht erwähnenswert, da das bei jedem Objekt so ist.

Ok, damit kann ich mitgehen.

Du kannst Eigenschaften und Methoden ändern, aber auf den Wert eines Objektes an sich, hast du in JS ja keinen Zugriff.

Aber hier hab ich möglicherweise noch ein Verständnisproblem. Wenn der Wert eines Boolean-Objektes true oder false und nicht änderbar ist, was ist dann der Wert eines Date-Objekts

( ) gar keiner. Datum und Zeit sind Eigenschaften, weswegen man sie mit setIrgendwas() ändern kann.
  ( ) was anderes: _________________

Lo!

[Struppi]

Du kannst Eigenschaften und Methoden ändern, aber auf den Wert eines Objektes an sich, hast du in JS ja keinen Zugriff.

Aber hier hab ich möglicherweise noch ein Verständnisproblem. Wenn der Wert eines Boolean-Objektes true oder false und nicht änderbar ist, was ist dann der Wert eines Date-Objekts

( ) gar keiner. Datum und Zeit sind Eigenschaften, weswegen man sie mit setIrgendwas() ändern kann.
  ( ) was anderes: _________________

Ein Objekt.

Einen Wert an sich gibt es nicht, sondern nur ein Verhalten in entsprechenden Situationen, weil es die dazugehörigen Methoden gibt. Wenn du alert(dateObjekt) aufrufst, wird in Wirklichkeit die Methode toString() aufgerufen, die den Timestamp, der irgendwo in dem Objekt gespeichert ist formatiert und als Zeichenkette zurückgibt.

Struppi.

[dedlfix]

Hi!

Einen Wert an sich gibt es nicht, sondern nur ein Verhalten in entsprechenden Situationen, weil es die dazugehörigen Methoden gibt. Wenn du alert(dateObjekt) aufrufst, wird in Wirklichkeit die Methode toString() aufgerufen, die den Timestamp, der irgendwo in dem Objekt gespeichert ist formatiert und als Zeichenkette zurückgibt.

Muss man sich das beim Boolean-Objekt so ähnlich vorstellen, dass der Wert eigentlich eine Eigenschaft ist, die aber vor der Außenwelt geschützt ist und nur über die Methoden sichtbar wird?

Lo!

[Struppi]

Einen Wert an sich gibt es nicht, sondern nur ein Verhalten in entsprechenden Situationen, weil es die dazugehörigen Methoden gibt. Wenn du alert(dateObjekt) aufrufst, wird in Wirklichkeit die Methode toString() aufgerufen, die den Timestamp, der irgendwo in dem Objekt gespeichert ist formatiert und als Zeichenkette zurückgibt.

Muss man sich das beim Boolean-Objekt so ähnlich vorstellen, dass der Wert eigentlich eine Eigenschaft ist, die aber vor der Außenwelt geschützt ist und nur über die Methoden sichtbar wird?

Ich bin auch nicht so der Fachmann. Aber bei den Browserobjekten kann ich mir vorstellen, dass das genauso implementiert ist. Das Prinzip ist ja das was OOP ausmacht, transparente Schnittstellen und verborgene Werte auf die man von aussen keinenZgriff hat.

Struppi.

[molily]

Hi,

Die Primitives als Objects, also new String, new Boolean, new Number, haben m.E.n. keine Anwendungsfälle. Im Gegenteil, sie verwirren die Anwender. Ich habe noch nie gesehen, dass die jemand zu seinem Vorteil genutzt hat, sondern immer nur aus Versehen, und dann war's eine Fehlerquelle.

Momentan googelt man nach »JavaScript Boolean« und stößt auf die SELFHTML-Seite, auf der etwas von »boolschen Konstanten« erzählt wird. Es ist lediglich ein Objekt, dass bei valueOf einen Boolean zurückgibt. Gut, daraus könnte man jetzt irgendeinen Nutzen in Richtung »Konstante« ableiten. Ich würde das aber nicht verwenden, weil die Nachteile zu groß sind. Z.B. ergibt  ein Vergleich von zwei new Boolean(true) false, weil zwei Objects verglichen werden.

Dass es die Primitives als Objects gibt, sollte an irgendeiner Stelle angemerkt werden, aber nur, um von ihrer Nutzung abzuraten. Ich halte es daher für Quatsch, eine eigene Seite einzurichten, die sich nur mit new Boolean beschäftigt. Die einzige relevante Info ist, dass man new Boolean nicht braucht und man besser die Literal-Primitives true und false verwenden sollte.

Eventuell Sinn macht die Arbeit mit eigenen Objekten, die ein einen Primitive wrappen (z.B. Number) sowie valueOf, toString und weitere eigene Methoden und Eigenschaften anbieten: Beispiel. Das ist allerdings noch was anderes als new String/Boolean/Number und ein absoluter Sonderfall.

Mathias

[molily]

Ich würde das aber nicht verwenden, weil die Nachteile zu groß sind. Z.B. ergibt  ein Vergleich von zwei new Boolean(true) false, weil zwei Objects verglichen werden.

Das ist ja noch harmlos im Vergleich zu
if (new Boolean(false)) { alert('foo'); }
d.h. Boolean(new Boolean(false)) ergibt true, weil new Boolean vom Typ Object ist.

Das ist definitiv einer der »Bad Parts« von JavaScript, die man unbedingt vermeiden sollte. »This turns out to be completely unnecessary and occasionally confusing. Don't use new Boolean or new Number or new String.« (Douglas Crockford, JavaScript: The Good Parts)

[Don P]

Hallo,

if (new Boolean(false)) { alert('foo'); }
d.h. Boolean(new Boolean(false)) ergibt true, weil new Boolean vom Typ Object ist.

Stimmt, aber sobald man einen Vergleich mit einem Primitive-Value anstellt, zeigt sich der initialisierte Wert, weil dann die ValueOf()-Methode des Objekts herangezogen wird:

if (new Boolean(false)==false) { alert('foo'); } ergibt true, genau wie if (new Boolean(true)==true) { alert('foo'); }

Das ist definitiv einer der »Bad Parts« von JavaScript, die man unbedingt vermeiden sollte. »This turns out to be completely unnecessary and occasionally confusing. Don't use new Boolean or new Number or new String.« (Douglas Crockford, JavaScript: The Good Parts)

Ja, da hat Crockford wohl recht. Es ist sehr verwirrend und new Boolean() wird so gut wie nie wirklich gebraucht, d.h. es gibt vermutlich immer einen anderen, weniger verwirrenden Weg.

Gruß, Don P

[molily]

sobald man einen Vergleich mit einem Primitive-Value anstellt, zeigt sich der initialisierte Wert, weil dann die ValueOf()-Methode des Objekts herangezogen wird

Ja, richtig, das macht die Sache umso perfider. I.d.R. ist es redundant, if (irgendwas == true) oder if (irgendwas == false) zu schreiben. Das machen meist Anfänger. Nach und nach gewöhnt man es sich zurecht ab und lässt das explizite == true/false weg (wenn es denn nicht === sein muss).

Dass es hier tatsächlich einen Unterschied macht, ob man if (value) oder if (value == true) schreibt, ist m.E. ein ultrafieser Fallstrick, den man auf jeden Fall umgehen sollte, weil er jeglicher Intuition widerspricht.

Mathias

[dedlfix]

Hi!

Die Primitives als Objects, also new String, new Boolean, new Number, haben m.E.n. keine Anwendungsfälle. Im Gegenteil, sie verwirren die Anwender. Ich habe noch nie gesehen, dass die jemand zu seinem Vorteil genutzt hat, sondern immer nur aus Versehen, und dann war's eine Fehlerquelle.

Danke für deine Antwort, das ist mehr als die Bestätigung meiner Ansicht zum Boolean-Objekt. Ich denke nun, man könnte der Vollständigkeit halber zwar das Boolean-Objekt und seine Eigenschaften/Methoden beschreiben (und vielleicht die Beispiele wegen zweifelhafter Sinnigkeit weglassen), aber gleich zu Anfang einen noch deutlicheren Hinweis auf die Primitives und die möglichen Nachteile beim Objekt hinzufügen.

Lo!

[Der Martin]

Hallo,

Ich denke nun, man könnte der Vollständigkeit halber zwar das Boolean-Objekt und seine Eigenschaften/Methoden beschreiben (und vielleicht die Beispiele wegen zweifelhafter Sinnigkeit weglassen)

ich würde gerade wegen der seltsamen und unerwarteten Ergebnisse ein oder zwei Beispiele zeigen, um dann daraus ein Fazit zu ziehen und "... deshalb von der Verwendung des Boolean-Objekts abraten".

Ciao,
 Martin

[dedlfix]

Hi!

Ich denke nun, man könnte der Vollständigkeit halber zwar das Boolean-Objekt und seine Eigenschaften/Methoden beschreiben (und vielleicht die Beispiele wegen zweifelhafter Sinnigkeit weglassen)

ich würde gerade wegen der seltsamen und unerwarteten Ergebnisse ein oder zwei Beispiele zeigen, um dann daraus ein Fazit zu ziehen und "... deshalb von der Verwendung des Boolean-Objekts abraten".

Da "oben" in der allgemeinen Warnung sollen ja solche abschreckenden Beispiele ruhig stehen, nur braucht es dann keine mehr für die Eigenschaften- und Methodenaufzählung. Wenn deren Verwendung in der Regel unsinnig ist, muss man auch kein wenig sinnvolles Beispiel dazu bringen, finde ich. Wenn es doch jemand verwenden will, muss/wird er erfahren/clever genug sein, das auch so anwenden zu können.

Lo!

[peterS.]

gruss dedlfix,

es gibt genau einen Grund für die Existenzberechtigung des [[Boolean]]-
Konstruktors - er kann, wie alle Konstruktor-Funktionen, prototypisch
um Eigenschaften bzw. Methoden erweitert werden.

Dieser Anwendungsfall sollte häufiger Auftreten (1+n) als der Missbrauch
dieses Konstruktors zur Instantiierung von boolean-Objekten (0).

Bsp.:

[link:http://github.com/petsel/javascript-api-extensions/blob/master/core/smalltalk-inspired-control-structures/Boolean.ifTrue.ifFalse.js@title=Boolean.prototype.ifTrue] = (function (fct) {  
  // ...  
});  
Boolean.prototype.ifFalse = (function (fct) {  
  // ...  
});  
  
condition().ifTrue(function () {  
  // ...  
}).ifFalse(function () {  
  // ...  
});

wobei [condition] eine komplexe Funktion sei, von der man nur weiss,
dass sie irgendeinen boolschen Zustand zurückgibt.

so long - peterS. - [e-mail]

[Don P]

Hallo,

es gibt genau einen Grund für die Existenzberechtigung des [[Boolean]]-
Konstruktors - er kann, wie alle Konstruktor-Funktionen, prototypisch
um Eigenschaften bzw. Methoden erweitert werden.

Abgesehen von prototypischer Erweiterung ist noch denkbar, dass man einen booleschen Wert als einzelne Eigenschaft eines Objekts per Referenz an eine Funktion übergeben will. Der Wert kann dann von der Funktion geändert werden, so dass die Eigenschaft im Ursprungsobjekt dann ebenfalls geändert ist, aber ohne dass die Funktion das Objekt "kennen" muss.

An den Haaren herangezogenes Beispiel:

function Trinkglas(form) {  
  this.form = form;  
  this.voll = new Boolean(false);  
};  
  
function einschenken(voll) {  
  if(!voll) voll.valueOf = function(){return true};  
}  
  
var meinglas = new Trinkglas("Sekt"),  
    deinglas = new Trinkglas("Whisky");  
  
einschenken(meinglas.voll);  
einschenken(deinglas.voll);  
  
alert(meinglas.voll==true); // true  
alert(deinglas.voll==true); // true  

Die Funktion "einschenken" bekommt nur eine Trinkglas-Eigenschaft "voll" übergeben, kennt also nicht das eigentliche Trinkglas-Objekt, und kann es dennoch füllen. :)

Interessanterweise funktioniert dass aber nicht, wenn man am Ende notiert:

alert(meinglas.voll); // false  
alert(deinglas.voll); // false  

Man muss schon wie oben einen Vergleich anstellen oder eine doppelte Verneinung bemühen um an den neuen Wert zu kommen:

alert(!!meinglas.voll); // true  
alert(!!deinglas.voll); // true  

~~~``{:.language-javascript}  
  
Gruß, Don P  

[Don P]

Hallo,

Man muss schon wie oben einen Vergleich anstellen oder eine doppelte Verneinung bemühen um an den neuen Wert zu kommen

Habe gerade festgestellt, dass die doppelte Verneinung auch nicht zuverlässig greift. Man sollte vorsichtshalber in solchen Fällen (aber wer bracuht das schon?) immer mit einem primitiven Wert vergleichen, um das richtige Ergebnis zu bekommen. im Beispiel oben also:

function einschenken(voll) {  
   if(voll==false) voll.valueOf = function(){return true};  
}

und zum Abfragen nach dem Einschenken dann:

alert(meinglas.voll==true); // true  
alert(deinglas.voll==true); // true  

Gruß, Don P

[dedlfix]

Hi!

Es geht immer noch um den Wiki-Artikel zum Boolean-Objekt. Den habe ich nun entsprechend der Ergebnisse dieses Thread umgearbeitet. Wenn ihr den nochmal gegenlesen und korrigieren wollt, tut euch keinen Zwang an.

Lo!

[romy]

Hallo dedlfix,

ich benutze jetzt mal diesen Thread um zu fragen, wo ich Fragen stellen kann, wenn ich etwas Beratung zum Wiki-Einpflegen brauche. Ich habe bewusst mit einem kleinen, eher unbedeuteten Beispiel begonnen um mal zu schauen wie es so geht. Ich hatte zwischendrin aber einige Fragen, die für die Diskussion aber zu banal (oder mir peinlich) waren. Gibts es eine Funktion, wo man sich Nachrichten schrieben kann, oder so?

Ich hab ja auch ein paar Fehler gemacht, die ich vielleicht vorher hätte klären können. Die Diskussionseiten finde ich irgendwie ungeeignet.

Viele Grüße
romy

[dedlfix]

Hi!

ich benutze jetzt mal diesen Thread um zu fragen, wo ich Fragen stellen kann, wenn ich etwas Beratung zum Wiki-Einpflegen brauche.

Hier im Forum kannst du das auf alle Fälle auch. Ansonsten, wenn es um ein Problem an einer konkreten Seite geht, dann kannst du auf der dortigen Diskussionsseite fragen. Für allgemeine Fragen habe ich gerade Hilfe:Fragen vorgesehen (existiert noch nicht wirklich, einfach bei Bedarf erstellen).

Ich habe bewusst mit einem kleinen, eher unbedeuteten Beispiel begonnen um mal zu schauen wie es so geht. Ich hatte zwischendrin aber einige Fragen, die für die Diskussion aber zu banal (oder mir peinlich) waren.

In deinem Benutzer-Namensraum kannst du Dinge probieren, und wenn du dort eine Diskussionsseite erstellst und eine Frage hinschreibst, wird sie auch mindestens von zwei Personen bemerkt.

Gibts es eine Funktion, wo man sich Nachrichten schrieben kann, oder so?

Ja, private Nachrichten kann man an einzelne Benutzer senden, wenn diese eine E-Mail-Adresse konfiguriert haben. Allerdings sollte man das nur bei persönlichen Dingen tun, nicht bei allgemeinen Fragen.

Lo!

[Vinzenz Mai]

Hallo romy,

Ich habe bewusst mit einem kleinen, eher unbedeuteten Beispiel begonnen um mal zu schauen wie es so geht. Ich hatte zwischendrin aber einige Fragen, die für die Diskussion aber zu banal (oder mir peinlich) waren.

In deinem Benutzer-Namensraum kannst du Dinge probieren, und wenn du dort eine Diskussionsseite erstellst und eine Frage hinschreibst, wird sie auch mindestens von zwei Personen bemerkt.

in vielen Fällen vermutlich von mindestens drei :-)

Freundliche Grüße

Vinzenz

[Beat]

Hallo romy,

Ich habe bewusst mit einem kleinen, eher unbedeuteten Beispiel begonnen um mal zu schauen wie es so geht. Ich hatte zwischendrin aber einige Fragen, die für die Diskussion aber zu banal (oder mir peinlich) waren.

In deinem Benutzer-Namensraum kannst du Dinge probieren, und wenn du dort eine Diskussionsseite erstellst und eine Frage hinschreibst, wird sie auch mindestens von zwei Personen bemerkt.

in vielen Fällen vermutlich von mindestens drei :-)

miro + miro + miro ?

metaphysisches Gruseln.

mfg Beat