Facebook
Twitter
Google+
Kommentare
5

PHP und das Typehinting-Verhalten

Ich liebe die Objektorietierung und den berühmt gewordenen Satz „everything is an object“ von Bruce Eckel habe ich habe ich mir sozusagen virtuell auf die Stirn tätowieren lassen. Aus diesem Grund war ich auch der erste, der auf dem Tisch getanzt hat, als das typeginting mit PHP5 eingeführt wurde. Endlich hatte man den ersten Schritt in Richtung Typsicherheit gemacht. Die schwache Typisierung von PHP stört mich bei den Basistypen wie String, Interger oder Boolean keinesfalls, nur leider klappt das Handling bei Objekten nicht immer auf diese Weise. 

Aber PHP wäre ja nicht PHP, wenn sie nicht mal wieder eine Kleinigkeit angebaut hätten, die mich mal wieder zum Stutzen bringt. Ich fange einfach mal mit einem einfachen Beispiel an. Wir haben folgenden einfachen Code:

class A
{
}

class B
{
}

class C
{
  public function doSthWithA( A $a )
  {
  }
}

Ich würde mal sagen, dass wir hier das einfachste Beispiel für das Typehinting bei Funktion in PHP haben. So fangen wir mal an uns aufzuregen:

  $a = new A;
  $c = new C;
  $c->doSthWithA( $a );

Dieser Codesnipet zeigt wunderbar wie schön PHP mit seinem „neuen“ Feature umgeht. Der Code läuft ohne abzubrechen durch, da wir alle Regeln die in Klasse definiert wurden befolgen. So weit so gut. Sind wir jetzt aber mal frech und geben der doSthWithA Methode doch einfach ein Objekt vom Typ B mit.

  $b = new B;
  $c = new C;
  $c->doSthWithA( $b );

Ganz klar, was der geschulte Informatiker jetzt erwarten würde. Ich habe der Methode gesagt, dass sie nur mit der Klasse A oder ihrer Kinder zurecht kommt, also muss ein Fehler auftauchen. Aber neeeee … PHP gibt zwar eine Nachricht aus, das hier etwas nicht stimmt, trotzdem macht er mit dem Wert, den er bekommt einfach weiter, in der Hoffnung, dass es schon klappen wird. Also meiner Meinung nach ist das nicht nur einfach falsch, sondern auch eine große Sicherheitslücke. 

Aber zum Glück habe ich gerade rausgefunden, dass PHP in den neueren Versionen nicht mehr reagiert, wie ich gerade beschrieben habe. Die Jungs von PHP scheinen also auch dazu zu lernen. Bravo. Ab jetzt wird ein catchable fatal error geworfen. Macht zwar meiner Meinung nach auch nicht so viel Sinn, denn hier liegt ganz klar ein Programmierfehler vor, wenn so ein Error auftaucht, den man auch nicht fangen sollte, sondern ihn umgehen muss. 

Also als Fazit kann man sagen, dass Typehining ein Feature ist, dass PHP wirklich eine eine neue Liga befördert, die Umsetzung ist aber wieder nur halbherzig geworden.

Über den Autor

Nils Langner

Nils Langner ist der Gründer von "the web hates me" und auch der Hauptautor. Im wahren Leben leitet er das Qualitätsmanagementteam im Gruner+Jahr-Digitalbereich und ist somit für Seiten wie stern.de, eltern.de und gala.de aus Qualitätssicht verantwortlich. Nils schreibt seit den Anfängen von phphatesme, welches er ebenfalls gegründet hat, nicht nur für diverse Blogs, sondern auch für Fachmagazine, wie das PHP Magazin, die t3n, die c't oder die iX. Nebenbei ist er noch ein gern gesehener Sprecher auf Konferenzen. Herr Langner schreibt die Texte über sich gerne in der dritten Form.
Kommentare

5 Comments

  1. Seit 5.2 wird der catchable fatal error geworfen, aber die Ausführung nicht abgebrochen. Mit 5.3 wird dann auch die Ausführung komplett abgebrochen, sofern man das nicht über einen eigenen error handler abwickelt (z.B. im error handler eine Exception werfen und irgendwo ein try-catch drumherum, um die wieder zu fangen).

    Reply
  2. Hallo Frank, vielen Dank für deine Anmerkung, leider hatte ich die Versionsdaten nicht auf Anhieb auf php.net gefunden und deswegen leider weglassen müssen.

    Reply
  3. Eigentlich interpretiere ich dieses Psoting als getrolle aber denoch ein Hinweise: Catchable Fatal Error heißt, das man ne Möglichkeit zu reagieren hat, es schreibt nunmal nicht jeder fehlerfreien Code, so wie Du, scheinbar. Der Catchable Fatal Error ermöglicht es denen, die sich für minimal fehlbar halten, dem User noch eine Fehlermeldung zu präsentieren, die Aussagekräftiger als eine weiße Seite (die er ja bekommen würde, da man PHP Fehlermeldungen nciht zeigt) ist.

    Absolut richtig wäre natürlcih eine Fehlermeldung vom Compiler – das geht in einer dynamisch typisierten Sprache aber nicht.

    Ah und zum Kritipunkt,. dass das mal ruhig gewesen ist: Habe jetzt extra nochmal in meiner PHP-Sammlung gewühlt und kann dies nicht nachvollziehen, PHP 4 gibt mir nen Parse Error (was klar ist), alte 5er geben nen Fatal Error, der terminiert, ab 5.2 nen Catchable Fatal Error. Und die Anmerkung dass das ne Sicherheitslücke wäre kann ich noch wneiger nachvollziehen: Die Konsequenz wäre ja das ein Objekt vom falschen Typ übergeben wird, das führt dann später zu einem Fatal Error o.ä. und ist jedenfalls ein Programmierfehler.

    Reply
  4. So endlich mal wieder im Code aufgetaucht:

    UNKNOWN ERROR [4096]: Argument 1 passed to CodeGenerator_Document::addClass() must be an instance of CodeGenerator_Class, instance of evoGen_Prototype_Model_Class given, called in /var/www/nl.neroweb-dev/Dev/lab/CodeGenerator/CodeGenerator.php on line 163 and defined
    in line 122 of file /var/www/nl.neroweb-dev/Dev/lab/CodeGenerator/CodeGenerator.php, PHP 5.2.3-1ubuntu6.3 (Linux)
    ——
    Und er führt definitiv den Code in der Methode aus.

    Reply

Leave a Comment.

Link erfolgreich vorgeschlagen.

Vielen Dank, dass du einen Link vorgeschlagen hast. Wir werden ihn sobald wie möglich prüfen. Schließen