PHP und das Typehinting-Verhalten

Lesetipps

1. Typehinting für einfache Typen
2. Undefinierte Attribute
3. Pfadabdeckung vs. Codeabdeckung

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.

5 Kommentare »

• 
  

  Frank Kleine

  am 10. September 2008 um 15:17 Uhr

  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).

• 
  

  admin

  am 10. September 2008 um 15:58 Uhr

  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.

• 
  

  Interview mit Nils Langner - Teil 1 | PHP hates me

  am 18. September 2008 um 20:31 Uhr

  [...] sollte, dann wäre es ganz klar das Problem beim Refactoring. Oder war es vielleicht doch das Typehinting Verhalten? Um ehrlich zu sein, ich weiß es nicht mehr. Irgendwann habe ich mal einen Satz von einem [...]

• 
  

  Johannes

  am 9. Oktober 2008 um 16:21 Uhr

  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.

• 
  

  admin

  am 15. Dezember 2008 um 14:49 Uhr

  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.

RSS Feed für Kommentare zu diesem Artikel. TrackBack URL

Hinterlasse einen Kommentar