tami: Rückgabewert von Methoden - typsicherer Vergleich

Beitrag lesen

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