nicht angemeldet
hi Sven,
Moin!
Also ich sage mal, dass das "nicht sinnvoll" ist und gebe folgenden Code zu bedenken:
Du kannst immer Code konstruieren, der den Unsinn irgendeiner Methode demonstriert.
Nö, mit "===" nicht, oder?
Macht ziemlich viel Sinn im richtigen Kontext - und genau darum gehts. Wenn ich annähernd identische Arrays aus derselben Quelle kriege und sie vergleichen will, aber die Key-Reihenfolge ist eventuell unterschiedlich...
Ja, ich wüsste jetzt zwar nicht, wie man das zustande kriegt, dass die Arrays nicht die korrekte Reihenfolge haben, aber mag ja sein. Die Kosten ("trade off" - s. Link zu Crockfords Vortrag) sind, dass die Werte im Array auch nur mit "==" verglichen werden. Wenn Du sagst, dass die Quelle sicher ist und dieser Vergleich (wahrscheinlich ;-) keinen Fehler produziert, ist das ja ein gutes Beispiel.
Mein Gegenbeispiel:
$myArray1[0] = "1abc";
$myArray1[1] = "1cde";
$myArray2[1] = "1cde";
$myArray2[0] = "1abc";
var_dump($myArray1 == $myArray2);
var_dump($myArray1 === $myArray2);
> Ergebnis: bool(true) und bool(false)
O.k., die Alternative mit 100%igem Vergleich des Inhalts:
~~~php
$myArray1[0] = "1abc";
$myArray1[1] = "1cde";
$myArray2[1] = "1cde";
$myArray2[0] = "1abc";
var_dump($myArray1 == $myArray2); // Inhalt wird "nur" mit "==" verglichen
sort($myArray1);
sort($myArray2);
var_dump($myArray1 === $myArray2); // Inhalt ist jetzt 100% ident geprüft
Klar, zwei Zeilen mehr mit jeweils einmal sort();
Sortieren kostet Zeit. Und ich muss direkt zweimal sortieren, statt direkt nur einmal zu vergleichen.
Wobei wohl 1. der PHP-Prozessor sowieso intern sotieren muss, sonst kriegt er die beiden Arrays ja nicht verglichen und 2. du nicht 100% sicher bist, dass die Inhalte/Werte 100% ident sind.
Ich füge hier mal den Link zum Crockfordvortrag ein, mit einer "Trackliste" bis zum zweiten drittel (double vs. triple equal).
Programming Style and Your Brain
14:48 - on javascript, but applicable for all languages
16:58 - hey my code does not work
17:15 - discipline
17:44 - jslint will hurt your feeling
18:44 - curly braces (coding style) - left or right
20:22 - start making up reasons (for left or right)
21:17 - be consitent [klar]
22:28 - design-error (semikolon insertion) [only javascript]
23:07 - prefer forms that are error resistant
23:29 - 0 cost big benefit
23:47 - switch statement story
26:07 - "that hardly ever happens" is another way of saying "it happens"
27:33 - good style can produce better programs
29:39 - reducing error rate in mideval
31:10 - programs must communicate clearly to people
32:04 - spaces
33:46 - immediately invocable function expressions [only javascript]
35:50 - semikolon insertion again [javascript only]
36:15 - with-statement [dont use] ... 37:15 "but sometimes its usefull..."
37:00 - confusion must be broken
37:30 - double equal vs. triple equal (its hard to tell if its beeing used right)
39:00 - If there is a feature of a language that is sometimes problematic,
and if it can be replaced with another feature that ist more reliable,
then always use the more reliable feature
... geht noch weiter, ingesamt eine Stunde.
mfg
tami
Matthias Apsel