Ankündigung

Einklappen
Keine Ankündigung bisher.

Typschwache Vergleiche PHP8

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Typschwache Vergleiche PHP8

    Für typschwache Vergleiche habe ich es so in Erinnerung dass wenn mindestens eine Seite einen numerischen Wert darstellt beide Seiten zu Integer gecastet werden und dann verglichen werden.

    PHP-Code:
    var_dump("42" == " 42");  //true 
    Nun hat sich mit PHP8 da einiges geändert. Beispiel:

    PHP-Code:
    var_dump(42 == "42a");  //false PHP8, true  PHP7 
    Unter PHP8 wird aber nach wie vor beim casten von "42a" zu int eine 42 geliefert.

    PHP-Code:
    var_dump((int)"42x");  //int(42) 
    Leerzeichen und Steuerzeichen werden beim Vergleich scheinbar ignoriert.

    PHP-Code:
    var_dump(42 == "42.");  // true
    var_dump(42 == " 42 \t\n");  //true
    var_dump("42" == " 42");  //true 
    Meine obige Gedankenstütze ist damit hinfällig. Etwas an Hintergrundinformationen fand ich hier. Insgesamt wirkt das alles etwas halbherzig auf mich.

    Bei solch grundlegenden Änderungen dürfte es an der einen oder anderen Stelle beim Umstieg auf PHP8 mal krachen. Gut beraten ist dann jeder der vorzugsweise auf typstrenge Vergleiche setzt.

    Der Grund für diese Änderung erschließt sich für mich nicht. Weis hier jemand mehr?







  • #2
    Zitat von jspit Beitrag anzeigen
    Der Grund für diese Änderung erschließt sich für mich nicht. Weis hier jemand mehr?
    Da ist die RFC zu https://wiki.php.net/rfc/string_to_number_comparison

    Zusammengefasst: Es soll "logischer" sein, aber möglichst die BC wahren.

    Untermstrich ist die Lösung aber auch nur ein Kompromis.

    Kommentar


    • #3
      Zitat von erc Beitrag anzeigen
      Es soll "logischer" sein
      Schön formuliert. Merke immer mehr, das ich mit der heutigen Logik Probleme habe. Mal das Einführungsbeispiel aus der RFC:
      PHP-Code:
      $validValues = ["foo""bar""baz"];
      $value 0;
      var_dump(in_array($value$validValues));
      // bool(true) WTF??? 
      Was würde man als Array-Inhalt erwarten wenn nach einem Integer $value gesucht werden soll und das Array nicht wie hier sichtbar ist?
      Ein Array aus numerischen Werten. Und genau das macht PHP bis zur Version 7.4. Würde ich Strings im Array erwarten, dann schreibe ich das so:
      PHP-Code:
      $validValues = ["foo""bar""baz"];
      $value "0";
      var_dump(in_array($value$validValues));
      //bool false 
      Sehe für mein Verständnis von Logik keine Veranlassung das Verhalten im ersten Skript mit PHP8 ändern zu müssen so das jetzt auch false raus kommt.

      Dagegen liefert der folgende Test
      PHP-Code:
      $validValues = ["foo""\t0e1\n""baz"];
      $value "0";
      var_dump(in_array($value$validValues)); 
      von PHP5.6 bis 7.4 ein bool(false) als Ergebnis. Mit PHP8 jedoch plötzlich true (Sandbox). Dieses Verhalten ist für mich nicht mehr logisch.
      In Anbetracht der Auswirkungen (if-Bedingungen, Array-Funktionen, Sortierungen etc.) bin ich mal gespannt was da noch alles an Überraschungen auf uns wartet.

      * Für in_array() habe ich ja noch die Möglichkeit das Verhalten mit dem 3.Parameter $strict zu beeinflussen. Mit strict = true bekomme ich auch für den ersten Srkipt das Resultat false.
      Diese Möglichkeit ist aber nicht immer gegeben.

      Kommentar


      • #4
        Zitat von jspit Beitrag anzeigen
        Sehe für mein Verständnis von Logik keine Veranlassung das Verhalten im ersten Skript mit PHP8 ändern zu müssen so das jetzt auch false raus kommt.
        Das ist wirklich strange. Keine Ahnung ob das absichtlich war oder ein Nebeneffekt von anderen Änderung.

        Zitat von jspit Beitrag anzeigen
        * Für in_array() habe ich ja noch die Möglichkeit das Verhalten mit dem 3.Parameter $strict zu beeinflussen. Mit strict = true bekomme ich auch für den ersten Srkipt das Resultat false.
        Diese Möglichkeit ist aber nicht immer gegeben.
        Das schaff die Möglichkeit. Das ist generelles Problem wenn der Computer "mitdenkendet". Das funktioniert vielleicht in den meisten Fällen, aber irgendwann fällt es dir auf die Füße.
        PHP bietet mittlerweile ja einiges was dir als Entwickler die Kontrolle über den Datentyp gibt. Wenn sies dann endlich mal schaffen, dass Array Keys den Datentyp behalten (derzeit wird alles was nach Zahl aussieht zu einem Integer), wird da auch eine runde Sache draus.

        Kommentar


        • #5
          Zitat von erc Beitrag anzeigen
          Das ist wirklich strange. Keine Ahnung ob das absichtlich war oder ein Nebeneffekt von anderen Änderung.
          So wie ich das sehe volle Absicht. Habe das Beispiel aus deinem Link zur RFC gewählt, da dieses Beispiel sozusagen der Aufhänger für die grundlegenden Änderungen des Verhaltens in der Version 8 ist.
          Kann auch sein das ich da aus der aus dem Artikel etwas falsch verstehe.

          Zitat von erc Beitrag anzeigen
          Das ist generelles Problem wenn der Computer "mitdenkendet". Das funktioniert vielleicht in den meisten Fällen, aber irgendwann fällt es dir auf die Füße.
          Das ist jetzt etwas OT: Da sehe ich vom Grundsatz kein Problem. Das "Mitdenken" muss jedoch logisch nachvollziehbar sein und keine Willkür die dazu führt das für jede Variante das Manual herhalten muss oder schlimmer noch ein extra Test her muss. Meine Klassen z.B. "denken" bei fast jeder Parameterübergabe mit. Beispiel DateTime-Klasse für das Erstellen eines Objektes. Wird ein String übergeben "03.03.2021" wird dieser geparst, ein Integer wird als Unix-Timestamp interpretiert, ein Float als Timestamp (mit Milli- und Mikrosekunden) und bei einem Objekt wird geprüft ob daraus ein Datum genommen werden kann. Kann mich nicht erinnern das mir das jemals "auf die Füße gefallen ist".

          Zitat von erc Beitrag anzeigen
          PHP bietet mittlerweile ja einiges was dir als Entwickler die Kontrolle über den Datentyp gibt. Wenn sies dann endlich mal schaffen, dass Array Keys den Datentyp behalten (derzeit wird alles was nach Zahl aussieht zu einem Integer), wird da auch eine runde Sache draus.
          Ist ein Ansatz worüber mal nachgedacht werden sollte. Hat aber so einige Konsequenzen, da dann "1" und 1 unterschiedliche Schlüssel darstellen. Kommt dann eine "1" aus einen Formularfeld muss dies gecastet werden um auf ein Array mit numerischen Schlüssel zugreifen zu können. Aber daran kann man sich gewöhnen. Dies ist so eine Sache die auch mit meinem Verständnis von Logik nachvollziehbar ist.

          LG jspit



          Kommentar

          Lädt...
          X