Rückgabewert von Methoden

[Naps]

Hi,

$STH->fetch() gibt ja "false" zurück, wenn keine Daten vorhanden sind. Ist daher so etwas richtig? Oder würdet ihr es anders lösen?

  
public function getData() {  
    $query = 'SELECT `feld` FROM `tabelle`';  
    $STH = $this->db->prepare($query);  
    $STH->execute();  
  
    if(($row = $STH->fetch()) !== false) {  
        return $row->feld;  
    }  
    return false;  
} 

Was wäre die beste Lösung wenn ich mehrere Zeilen auslese möchte?

while($row = $STH->fetch) {  
   $daten[] = $row->feld;  
}  
return $daten;

Oder gibt es eine bessere Lösung?

Oft frage ich mich auch, was ich danach mache wenn ich mit den Daten weiterarbeiten möchte. Es bleibt mir eigentlich keine andere Möglichkeit als jedesmal if(!empty()) zu prüfen oder?

Ich hoffe der letzte Absatz ist verständlich :D

MfG Naps

[hotti]

$STH->fetch() gibt ja "false" zurück, wenn keine Daten vorhanden sind. Ist daher so etwas richtig? Oder würdet ihr es anders lösen?

Ja. Meine Methoden geben immer eine Referenz auf die zu erwartenden Daten zurück, es sei denn, eine Exception ist gefallen (DB-Server abgeraucht, Verbindung abgebrochen o.ä.).

Sofern Benutzereingaben in die Abfrage eingehen, werden die vorher geprüft. In Perl sieht das bei mir in Etwa so aus:

  
# Wenn hier eine EX fällt, ist es höhere Gewalt wo  
# Anwender nichts dafür kann  
# Verbindung zum Data-Layer  
my $userobject = tie my %user, 'MySQL::User' or  
   die "$@\n";  
  
# Aber hier:  
# die Session-ID kommt vom Anwender  
# und könnte falsch sein  
  
$userobject->validate( $Session->user_id ) or  
   return $this->errorP( descr => "Unbekannte User-ID");  
  
# OK, hier kanns weitergehen  
$user{suburb} = "Mala Strana"; # aus einem Formular z.B.  
  
$userobject->write or die "$@\n";  
# mögliche EX beim Zurückschreiben  

Geht auch in PHP zu machen ;)

[T-Rex]

Ola,

früher hab ich mir die gleichen gedanken wie du gemacht. ISt das richtig? Ist das gut? Ist das ein guter Stil? Dann hatte ich noch einen Typen orientierten Chef, der aus der C Welt kam und in PHP die gleichen MEchanismen wie in C einführen wollte. Strikte Typen, stare Rückgabewerte. Daran musste ich mich Jahre lang halten und hab gedacht das wäre richtig so.

Dann kam JQuery in mein Leben...

Mein JQuery Code ist aufgeräumt, strukturiert, klein und macht genau was er soll. Die nutzen das Typenlose Verhalten von Javascript aber mal so richtig aus.
Du kannst als gleichen Parameter ein Objekt übergeben oder einen String oder einen Integer. Wäre meine eigene Webseite nicht schon so weit, ich würde versuchen ein PHP Framework der JQuery Syntax anzupassen.

Deshalb mach dir nicht so einen Kopf. Ob du jetzt null oder false zurück gibst ist "fast" egal. Vor allem wenn du nur prüfen willst ob ein Wert zurück gekommen ist. Wichtig ist, dass du dich selbst auskennst oder eine gute Dokumentation hast wo du alles festhälst.

Gruß
vereinfachter
T-Rex

[hotti]

Du kannst als gleichen Parameter ein Objekt übergeben oder einen String oder einen Integer. Wäre meine eigene Webseite nicht schon so weit, ich würde versuchen ein PHP Framework der JQuery Syntax anzupassen.

Interessanter Gedanke mein Lieber ;)

Interessant deswegen, weil auch ich mir diesbezüglich seit Jahren Gedanken mache: Transparente Datenstrukturen und: Endlich können moderne Browser mit Binärdaten umgehen. So habe ich in der Zeit, die vergangen ist bis Browser endlich soweit sind, mein Framework weiterentwickelt und dementsprechende Schnittstellen erst vor Kurzem zum Leben erweckt.

So werden komplexe Datenstrukturen per AJAX ganz einfach nur hin- und hergereicht und dadruch, dass diese Datenstrukturen Client- wie Serverseitig ganz genauso aufgebaut sind, ist eine Anwendung in extrem kurzer Zeit entwickelt, benutzerfreundlich, performant sowie zu einem moderaten Preis.

Viele Grüße!

[T-Rex]

So werden komplexe Datenstrukturen per AJAX ganz einfach nur hin- und hergereicht und dadruch, dass diese Datenstrukturen Client- wie Serverseitig ganz genauso aufgebaut sind

Die Idee hatte ich auch vor kurzem :D.
Einziges Problem das ich dabei sehe ist, dass man zwei Template Strukturen braucht. Aktuell habe ich aber nur ein PHP Template Framework. Ergo traue ich mich nicht "Roh-"Daten auf die JS Seite zu geben. Sonst müsste ich das ganze Template gedöns nochmal nachbauen. Ergo gibt es nur eine "Viewer" schicht und die ist im PHP und liefert immer HTML aus.
Wie hast du das Problem gelöst?

Gruß
HoT-Rex

[hotti]

hi,

Wie hast du das Problem gelöst?

Meine Template-Engine (TE, sprich HTML::Template o.ä.) kommt nur zum Einsatz, wenn Seiten komplett in HTML ausgeliefert werden müssen. In JS hingegen, arbeite ich nicht mit Templates sondern nur mit Datenstrukturen (sprich: Objekte).

Die serverseitige Business-Logik arbeitet ebenfalls nur mit Objekten als Datenträger. So ist z.B. serverseitig

$game->{score}{'Max Müller'};

clientseitig als

game.score['Max Müller'];

vorhanden und die Daten können synchronisiert oder anderweitig abgeglichen werden.

Von der Art der Verpackung ist das vollständig abstrahiert, das kann JSON sein, XML... oder halt meine eigene Entwicklung (binary safe) für zyklische Strukturen. Binary safe hat den Vorteil, dass sich der Entwickler keine Gedanken machen muss, ob da Bilddateien, HTML, oder Texte (Zeichenkodierung egal), oder alles zusammen übertragen wird.

Wahlfreier Datenzugriff also client- wie serverseitig auf quasi dieselben Objekte, Transparenz halt :)

Zum Erstellen einer kompletten HTML-Response kriegt das View-Model nur die Daten.
Zum Sendern einer AJAX-Response werden dieselben Daten nur serialisiert.

Viele Grüße!

[hotti]

Zum Sendern einer AJAX-Response werden dieselben Daten nur serialisiert.

^ Senden und Rendern

SCNR ;

[T-Rex]

In JS hingegen, arbeite ich nicht mit Templates sondern nur mit Datenstrukturen (sprich: Objekte).

Und wie kommen die Daten ins HTML?

Gruß
kurzer
T-Rex

[hotti]

Und wie kommen die Daten ins HTML?

Serverseitig als Binary in Ajax-Response (schicke 12 Monate)

  
    if($self->param('year')){  
        my $year = $self->param('year');  
        my $kw = Kalenderwoche->new(date => "1.1.$year") or  
            return $self->serialize2content({def => {errstr => "$@"}});  
  
        $self->serialize2content(\%server);  

Clientseitig

  
    var create = {  
        callback: function(buffer){  
            var eav = EAV.buffer2eav(buffer); // Erstelle ein Objekt  
            if(eav.def.errstr){  
                alert(eav.def.errstr); // evntl. war das Jahr falsch eingegeben  
                return;  
            }  
            else{  
                for(var mnr = 1; mnr <= 12; mnr++){  
                    _('htmlmonth_' + mnr).innerHTML = eav.ymonths[mnr];  
  
                }  
                return;  
            }  
        },  
  

In dem Moment wo Benutzer das Bild 'Aljoscha_in_der_Wolga.jpg' auf den Januar zieht, beschreibt JS ein Objekt:

  
Server.Jan.year = 1950;  
Server.Jan.imgbinary = arraybuffer; // FileReader.readAsArrayBuffer  
// Benutzer schreibt was dazu  
Server.Jan.text = "Boah, war das kalt...";  

Und wenn alles fertig ist, geht das Server-Objekt als Blob zum Server wo das PDF erstellt wird...

[T-Rex]

Also mittels ".innerHTML" beschreibst du den DOM Baum. Bei dem kleinen Problem mag das eventuell helfen.
Wenn du aber Änderungen hast die das halbe HTML umstürzten wirst du Probleme bekommen.

z.b. folgendes Problem.
Da gibt es Kommentare. 10 Kommentare sind bereits vorhanden es soll ein neuer Hinzukommen. Der User hat ein Formular das er ausfüllt und dann klickt er auf Senden. Anstatt einen Reload zu machen wird das Formular mittels Ajax an den Server geschickt und verarbeitet. JETZT hast du das Problem den Kommentar mit dem gewöhnten "Kommentar Template" anzuzeigen. Es gibt zwei Möglichkeiten. Entweder hast du einen ausgefeiltes System so das du die Kommentartemplate Files sowohl Serverseitig als auch Klientseitig benutzen kannst oder du baust den Kommentar mit extra Javascriptcode selbst zusammen. Bei einer Änderung der Kommentar Struktur musst du die Änderung natürlich in zwei Systemen vornehmen. Einmal Serverseitig in deinen Templates und Clientseitig in deinem JS.

Und hier stellt sich mir die Frage wie du das gelöst hast, sofern du jemals auf das Problem gestoßen bist. Wenn du das Formular "normal" abschicken lässt und einen Seiten Reload akzeptierst wirst du nie auf das Problem kommen.

Gruß
doppel moralischer
T-Rex

[hotti]

hi,

Und hier stellt sich mir die Frage wie du das gelöst hast, sofern du jemals auf das Problem gestoßen bist. Wenn du das Formular "normal" abschicken lässt und einen Seiten Reload akzeptierst wirst du nie auf das Problem kommen.

Jaja, schon klar, ein Submit kommt sowieso nicht in Frage und würde auch gar keine Daten liefern, weil die ja in einem JS-Objekt gespeichert sind. So werden auch die 12 Monate per ajax geliefert, sonst müsste der Benutzer mit seiner Bildauswahl wieder von vorne anfangen.

12 Monate an der richtigen Stelle einzuhängen ist ja nun wirklich kein Thema, das geht mit einem Schleifchen.

Aber: Ausgeliefert wird beim ersten Laden der Seite das Template mit dem HTML-Zeugs, wo die Daten später hinkommen (ajax oder Benutzereingaben) und auch die Drop-Areas sowie Bereiche im DOM wo Benutzer seine Kommentare hinschreibt. In diesem Template stehen die IDs schon drin, die werden bereits serverseitig erzeugt.

Schöne Grüße ;)

[hotti]

z.b. folgendes Problem.
Da gibt es Kommentare. 10 Kommentare sind bereits vorhanden es soll ein neuer Hinzukommen. Der User hat ein Formular das er ausfüllt und dann klickt er auf Senden. Anstatt einen Reload zu machen wird das Formular mittels Ajax an den Server geschickt und verarbeitet.

Nene, so nicht ;)

Alles, was Benutzer eingibt, Texte und Bilder, die er in den Browser schiebt, alldi-ese Daten werden sofort mit der Benutzeraktion in einem Objekt gespeichert. Und das geht dann nicht mit einem Submit wech sondern wird mit JS in eine Binary serialisiert per Ajax gesendet. Da wird höchstens noch ein Parameter mitgeliefert, wo serverseitig erkennbar ist, was als Antwort zurückkommen soll.

Btw., sofern die eingegeben Daten 10MB nicht übersteigen, kann User die Daten auch in localStorage zwischenlagern oder per SaveAs-Dialog lokal speichern (Arbeit unterbrechen, später wieder aufnehmen, Offlinebetrieb...).

Der Möglichkeiten gibt es viele, wenns unbedingt sein muss, geht auch ein Submit. Der Browser ist nur noch das Werkzeug zum Erstellen einer Hypermedia-Datei (Bilder, Texte, Audio, Video in einer Datei). Wenn User möchte, kann er die auch aufd CD brennen und mit DHL verschicken ;)

[T-Rex]

z.b. folgendes Problem.
Da gibt es Kommentare. 10 Kommentare sind bereits vorhanden es soll ein neuer Hinzukommen. Der User hat ein Formular das er ausfüllt und dann klickt er auf Senden. Anstatt einen Reload zu machen wird das Formular mittels Ajax an den Server geschickt und verarbeitet.

Nene, so nicht ;)

Alles, was Benutzer eingibt, Texte und Bilder, die er in den Browser schiebt, alldi-ese Daten werden sofort mit der Benutzeraktion in einem Objekt gespeichert. Und das geht dann nicht mit einem Submit wech sondern wird mit JS in eine Binary serialisiert per Ajax gesendet. Da wird höchstens noch ein Parameter mitgeliefert, wo serverseitig erkennbar ist, was als Antwort zurückkommen soll.

Ok also du speicherst die Kommentare einfach nur und zeigst sie nie mehr an.
Auch ein interessanter Ansatz.

Btw., sofern die eingegeben Daten 10MB nicht übersteigen, kann User die Daten auch in localStorage zwischenlagern oder per SaveAs-Dialog lokal speichern (Arbeit unterbrechen, später wieder aufnehmen, Offlinebetrieb...).

Mal abgesehen von der eigentlichen Antwort (die du nach wie vor nicht geliefert hast) ist das auch ein interessanter Ansatz. Wenn man das Formular auf der JS Seite in ein Objekt Umwandelt. Un das überträgt man an den Server per JSON und Ajax oder man speichert es im Browser. Das klingt gut.

Aber nach wie vor interessiert es mich brennend was vom Server an das JS wieder zurück kommt nachdem du es in ein Objekt gepackt und gespeichert hast.

Gruß
vor Neugier fast platzender
T-Rex

[hotti]

Ok also du speicherst die Kommentare einfach nur und zeigst sie nie mehr an.

Nene, die werden schon angezeigt: Draufklicken, der Text oder das markierte Element verwandelt sich in eine Textarea. Textarea verlassen: steht nur noch der Text da. Draufklicken: Schriepflehre korregeirn und solange, bis die Rechtschreibung stimmet.

Auch ein interessanter Ansatz.

Siehe oben ;)

Die Bilder werden auch gleich angezeigt, Bild auf die Droparea schieben, zack, isses da gleich sichtbar.

Btw., sofern die eingegeben Daten 10MB nicht übersteigen, kann User die Daten auch in localStorage zwischenlagern oder per SaveAs-Dialog lokal speichern (Arbeit unterbrechen, später wieder aufnehmen, Offlinebetrieb...).

Mal abgesehen von der eigentlichen Antwort (die du nach wie vor nicht geliefert hast) ist das auch ein interessanter Ansatz. Wenn man das Formular auf der JS Seite in ein Objekt Umwandelt. Un das überträgt man an den Server per JSON und Ajax oder man speichert es im Browser. Das klingt gut.

Das ist Saugut!!! Und vor allem Benutzerfreundlich :)

Mit dem neuen FormData-Objekt ist das ratzfatz gemacht ;)

Aber nach wie vor interessiert es mich brennend was vom Server an das JS wieder zurück kommt nachdem du es in ein Objekt gepackt und gespeichert hast.

Er sendet schlicht und einfach nur ein bischen Text: Vielen Dank für Ihre Bestellung. Sie erhalten eine Rechnung als PDF per Mail und die Drucksache per Nachnahme ;)

Aber danach wird die Seite neu gladen, ohne Pardon mit location.reload(true);

Du, ich hab das alles schon fertig. Und noch ein paar hübsche andere Sachen, die produktionsreif sind.

PS: Es gibt tatsächlich ein kleines Problem mit großen Dateien. Fakt ist jedoch, dass ein Upload einer 20-MB-Media-Datei via AJAX besser ist, als per Submit, mit AJAX gibt es eine Fortschrittsanzeige, beim Submit sieht der Benutzer minutenlang gar nix und das ist schlecht.

Wenn Fotos auf 18*24 cm gedruckt werden sollen, sie sollten mind. 150 dpi haben, JPGs liegen da so um die 200 kB.

[dedlfix]

Tach!

$STH->fetch() gibt ja "false" zurück, wenn keine Daten vorhanden sind.

Anderenfalls gibt es einen Wert zurück, der nicht zu false konvertiert.

if(($row = $STH->fetch()) !== false) {

Deswegen ist der typsichere Vergleich auch nicht notwendig.

Ist daher so etwas richtig? Oder würdet ihr es anders lösen?

Für welche Aufgabenstellung denn? Wie soll denn mit den zurückgegebenen Werten umgegangen werden?

Was wäre die beste Lösung wenn ich mehrere Zeilen auslese möchte?

Ein Array zurückgeben oder seit PHP 5.5 einen Generator.

Oder gibt es eine bessere Lösung?

Eine noch bessere als die beste? Es gibt ja sowieso keine "beste", ohne den Anwendungsfall zu betrachten.

Oft frage ich mich auch, was ich danach mache wenn ich mit den Daten weiterarbeiten möchte. Es bleibt mir eigentlich keine andere Möglichkeit als jedesmal if(!empty()) zu prüfen oder?

Wenn du ein Array oder einen Generator (oder auch Iterator) zurückgibst, hört das foreach von selbst auf, wenn alle Daten abgearbeitet sind.

dedlfix.

[tami]

hi dedlfix,

$STH->fetch() gibt ja "false" zurück, wenn keine Daten vorhanden sind.

Anderenfalls gibt es einen Wert zurück, der nicht zu false konvertiert.

if(($row = $STH->fetch()) !== false) {

Deswegen ist der typsichere Vergleich auch nicht notwendig.

Er hinterlässt aber keinen Zweifel. Das ist gut.

Es funzt auch anders, klar. s.a. http://forum.de.selfhtml.org/archiv/2013/10/t215185/#m1474005.

Ich halte es da - s. Link - mit Crockford: sei unmissverständlich, dann kannst Du Dich auf die wesentlichen Punkte Deines Codes konzentrieren. Gilt für JS wie für PHP.

mfg

tami

[dedlfix]

Tach!

if(($row = $STH->fetch()) !== false) {
Deswegen ist der typsichere Vergleich auch nicht notwendig.
Er hinterlässt aber keinen Zweifel. Das ist gut.

Bei mir hinterlässt er aber einen, weil ich erstmal nachschauen muss, ob nicht in dieser unzweifelhaft eindeutigen Situation die Logik umgedreht wird.

dedlfix.

[tami]

hi dedlfix,

Tach!

if(($row = $STH->fetch()) !== false) {
Deswegen ist der typsichere Vergleich auch nicht notwendig.
Er hinterlässt aber keinen Zweifel. Das ist gut.

Bei mir hinterlässt er aber einen, weil ich erstmal nachschauen muss, ob nicht in dieser unzweifelhaft eindeutigen Situation die Logik umgedreht wird.

Das kapier mal einer.

Uneindeutig und unvollständig erscheint mir das hier: http://us3.php.net/manual/en/types.comparisons.php.

Ebenso: "Return Values: The return value of this function on success depends on the fetch type."

Ganz eindeutig aber ist:  "In all cases, FALSE is returned on failure."

http://php.net/manual/en/pdostatement.fetch.php

Insofern ist logisch allein eindeutig richtig: $STH->fetch() !== false. Denn false ist der Rückgabewert bei einem Fehler. Und nicht "irgendwas was zurück kommt, sich aber nicht zu false casten lässt, zeigt an, dass kein boolsches False zurück kam". Sonst stünde da ja: "The return value depends on the fetch type, but you can be sure, that all that ist returned does not cast to Boolen-False, except on Failure, where exact Boole-False ist returned." Schon allein der krüppelige Versuch diese Logik in Worte zu fassen sollte doch schon zeigen, wir murx das ist. Muss irgendwas psychologisches sein, bei Dir und Sven, Crockford kommt in seinen Vorträgen auf dieses "ja, aber ..." ja immer wieder zu sprechen.

Hier soll doch faktensicheres Wissen und nicht "funzendes" vermittelt werden. Habe mich auch schon über Svens Beharrlichkeit bezüglich typenloser Vergleiche gewundert. Es kann schlicht immer zu einer Fehlerquelle werden und bzw. weil es (um ein Gleichheitszeichen zu sparen!) Fälle mit einschließt, die man überhaupt nicht eigentlich berücksichtigen möchte. Ich bin mir nach 10 Minuten Lektüre des Manuals immer noch nicht sicher, ob nicht doch ein leeres Array oder ein leeres Objekt wiedergegeben werden könnte. Und: ein leeres Objekt taucht in der typecasting-Tabelle garnicht auf. Oha ...;

mfg

tami

[dedlfix]

Tach!

Bei mir hinterlässt er aber einen, weil ich erstmal nachschauen muss, ob nicht in dieser unzweifelhaft eindeutigen Situation die Logik umgedreht wird.
Das kapier mal einer.

Da ist überflüssiger Code drin, zu dem verstanden werden will, ob er an der Logik was verdreht oder nicht.

Uneindeutig und unvollständig erscheint mir das hier: http://us3.php.net/manual/en/types.comparisons.php.

Sind doch alle Varianten drin, selbst die, die im vorliegenden Fall gar keine Geige spielen.

Ebenso: "Return Values: The return value of this function on success depends on the fetch type."
Ganz eindeutig aber ist:  "In all cases, FALSE is returned on failure."

Die anderen Fälle sind ebenfalls eindeutig. Da kommt immer etwas zurück, das nicht false werden kann. Es ist nur bei dieser Funktion etwas umfangreicher, weil die Rückgabemöglichkeiten vielfältiger sind. Aber du würdest ja genauso vehement die überflüssige Übereindeutigkeit verteidigen, wenn es zum Beispiel um mysqli_result::fetch_assoc() ginge, bei dem nur ein nichtleeres Array oder NULL zurückkommen kann.

Schon allein der krüppelige Versuch diese Logik in Worte zu fassen sollte doch schon zeigen, wir murx das ist. Muss irgendwas psychologisches sein, bei Dir und Sven, Crockford kommt in seinen Vorträgen auf dieses "ja, aber ..." ja immer wieder zu sprechen.

Es gibt Bauchmenschen und es gibt Kopfmenschen. Dein Crockford mag eher "don't let me think". Ich mag den Ansatz nicht, er verführt mir zu leicht zur Faulheit.

Hier soll doch faktensicheres Wissen und nicht "funzendes" vermittelt werden.

Wie PHP typecastet ist ausreichend genau dokumentiert. Es ist hingegen nicht fakt, dass allein Crockfords Ansatz der richtige ist.

Es kann schlicht immer zu einer Fehlerquelle werden und bzw. weil es (um ein Gleichheitszeichen zu sparen!) Fälle mit einschließt, die man überhaupt nicht eigentlich berücksichtigen möchte.

Diese Fälle haben wir hier nicht vorliegen. Es trotzdem so zu tun und keine Abweichung zu dulden, sehe ich eher als Prinzipienreiterei an.

Ich bin mir nach 10 Minuten Lektüre des Manuals immer noch nicht sicher, ob nicht doch ein leeres Array oder ein leeres Objekt wiedergegeben werden könnte.

Dazu müsstest du ein Resultset erzeugen können, dass zwar Zeilen hat, aber keine Spalten.

Und: ein leeres Objekt taucht in der typecasting-Tabelle garnicht auf. Oha ...;

Objekt ist immer true (außer in PHP4).

dedlfix.

[tami]

hi dedlfix,

Tach!

Bei mir hinterlässt er aber einen, weil ich erstmal nachschauen muss, ob nicht in dieser unzweifelhaft eindeutigen Situation die Logik umgedreht wird.
Das kapier mal einer.

Da ist überflüssiger Code drin, zu dem verstanden werden will, ob er an der Logik was verdreht oder nicht.

Diese Satz erschließt sich mir nicht.

Uneindeutig und unvollständig erscheint mir das hier: http://us3.php.net/manual/en/types.comparisons.php.

Sind doch alle Varianten drin, selbst die, die im vorliegenden Fall gar keine Geige spielen.

Genau.

Ebenso: "Return Values: The return value of this function on success depends on the fetch type."
Ganz eindeutig aber ist:  "In all cases, FALSE is returned on failure."

Die anderen Fälle sind ebenfalls eindeutig. Da kommt immer etwas zurück, das nicht false werden kann. Es ist nur bei dieser Funktion etwas umfangreicher, weil die Rückgabemöglichkeiten vielfältiger sind. Aber du würdest ja genauso vehement die überflüssige Übereindeutigkeit verteidigen, wenn es zum Beispiel um mysqli_result::fetch_assoc() ginge, bei dem nur ein nichtleeres Array oder NULL zurückkommen kann.

Aha, und?

Schon allein der krüppelige Versuch diese Logik in Worte zu fassen sollte doch schon zeigen, wir murx das ist. Muss irgendwas psychologisches sein, bei Dir und Sven, Crockford kommt in seinen Vorträgen auf dieses "ja, aber ..." ja immer wieder zu sprechen.

Es gibt Bauchmenschen und es gibt Kopfmenschen. Dein Crockford mag eher "don't let me think". Ich mag den Ansatz nicht, er verführt mir zu leicht zur Faulheit.

Das ist das Missverständnis. Danke für die Aufklärung. Es geht bei Crockford allein um die Minimierung von Fehlerquellen. Dein "Dein Crockford ..." reicht da eigentlich für die psychologische Erklärung schon aus.

Hier soll doch faktensicheres Wissen und nicht "funzendes" vermittelt werden.

Wie PHP typecastet ist ausreichend genau dokumentiert. Es ist hingegen nicht fakt, dass allein Crockfords Ansatz der richtige ist.

Nun ja, wenn ich auf bool-false testen will, sollte ich genau das tun.

Es kann schlicht immer zu einer Fehlerquelle werden und bzw. weil es (um ein Gleichheitszeichen zu sparen!) Fälle mit einschließt, die man überhaupt nicht eigentlich berücksichtigen möchte.

Diese Fälle haben wir hier nicht vorliegen. Es trotzdem so zu tun und keine Abweichung zu dulden, sehe ich eher als Prinzipienreiterei an.

Ja, das ist die Standard-Argumentation "gegen" Minimierung von Fehlerquellen.

Ich bin mir nach 10 Minuten Lektüre des Manuals immer noch nicht sicher, ob nicht doch ein leeres Array oder ein leeres Objekt wiedergegeben werden könnte.

Dazu müsstest du ein Resultset erzeugen können, dass zwar Zeilen hat, aber keine Spalten.

Jo, du lieferst ja selbst das Argument, gegen das du dich "wehrst".

Und: ein leeres Objekt taucht in der typecasting-Tabelle garnicht auf. Oha ...;

Objekt ist immer true (außer in PHP4).

Was mir ja egal sein kann, wenn ich auf bool-false abfrage, ganz schlicht und simpel ...;

mfg

tami

[dedlfix]

Tach!

Es geht bei Crockford allein um die Minimierung von Fehlerquellen.

Es gibt im vorliegenden Fall schlicht und einfach keine Fehlerquelle, die aufgrund von Typkonvertierung auftreten kann. Deshalb gibts da auch nichts durch zusätzlichen Code zu minimieren.

Ich bin mir nach 10 Minuten Lektüre des Manuals immer noch nicht sicher, ob nicht doch ein leeres Array oder ein leeres Objekt wiedergegeben werden könnte.
Dazu müsstest du ein Resultset erzeugen können, dass zwar Zeilen hat, aber keine Spalten.
Jo, du lieferst ja selbst das Argument, gegen das du dich "wehrst".

Bitte? Es ist nicht möglich, ein solches Resultset zu erzeugen.

dedlfix.

[Tom]

Hello,

Es gibt Bauchmenschen und es gibt Kopfmenschen. Dein Crockford mag eher "don't let me think". Ich mag den Ansatz nicht, er verführt mir zu leicht zur Faulheit.

Man sollte immer in die Doku gucken. Wenn man es nicht tut, kommen dann so Sachen, wie mysqli::execute($a, $b) raus :-O
Da hing der PHP-Doku-Cluster gerade...

Und es gíbt auch Funktionen in PHP, die geben 0 zurück für "alles OK" und -1 für einen Fehler. Da kann man auch auf die Schnauze fallen. Deshalb: immer gucken.

Aber wenn FALSE bedeutet "Fehler", dann finde ich es nicht falsch mit === zu vergleichen.

Gutes Beispiel dafür ist strpos(). Da wird 0 benötigt für "found at postition zero".

Da === nun mal eingeführt worden ist, kann man es auch benutzten, wenn es das Ergebnis nicht falsch machet. Und man muss öfter an den "strikten Vergleich" denken, sogar bei Array-Funktionen. Schau dir mal in_array() an, was da passieren kann, wenn der Vergleichswert false ist.

Die "Kopfmenschlichkeit" ist die Ausrede. "Ich weiß es besser, ich brauche keinen strikten Vergleich"...

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[tami]

hi Tom,

Es gibt Bauchmenschen und es gibt Kopfmenschen. Dein Crockford mag eher "don't let me think". Ich mag den Ansatz nicht, er verführt mir zu leicht zur Faulheit.

Man sollte immer in die Doku gucken. Wenn man es nicht tut, kommen dann so Sachen, wie mysqli::execute($a, $b) raus :-O
Da hing der PHP-Doku-Cluster gerade...

Und es gíbt auch Funktionen in PHP, die geben 0 zurück für "alles OK" und -1 für einen Fehler. Da kann man auch auf die Schnauze fallen. Deshalb: immer gucken.

Aber wenn FALSE bedeutet "Fehler", dann finde ich es nicht falsch mit === zu vergleichen.

Gutes Beispiel dafür ist strpos(). Da wird 0 benötigt für "found at postition zero".

Da === nun mal eingeführt worden ist, kann man es auch benutzten, wenn es das Ergebnis nicht falsch machet. Und man muss öfter an den "strikten Vergleich" denken, sogar bei Array-Funktionen. Schau dir mal in_array() an, was da passieren kann, wenn der Vergleichswert false ist.

Die "Kopfmenschlichkeit" ist die Ausrede. "Ich weiß es besser, ich brauche keinen strikten Vergleich"...

Nu ja, so in etwa das, was ich sagen wollte und wie ich Crockford verstehe. Ist mir nicht geglückt, dass so rüberzubringen wir aus meiner Sicht Dir in diesen Paar Sätzen ...;

mfg

tami

[dedlfix]

Tach!

Die "Kopfmenschlichkeit" ist die Ausrede. "Ich weiß es besser, ich brauche keinen strikten Vergleich"...
Nu ja, so in etwa das, was ich sagen wollte und wie ich Crockford verstehe. Ist mir nicht geglückt, dass so rüberzubringen wir aus meiner Sicht Dir in diesen Paar Sätzen ...;

Bei dieser Diskussion geht es euch nicht mehr um diesen speziellen Fall, sondern ihr versucht eine allgemeingültige Lösung zu propagieren, unabhängig von ihrer jeweiligen Notwendigkeit. Könnt ihr gern machen, ich bin raus.

dedlfix.