Aktualisiert (Mittwoch, den 24. Februar 2010 um 15:07 Uhr) Geschrieben von: Johannes Schlimm Donnerstag, den 04. Februar 2010 um 18:51 Uhr

Beitragsseiten
PHP mit MySQL ist populär. Aber...
Fortsetzung 1
Fortsetzung 2
Alle Seiten

 

Aber auch in neuerer Zeit gibt es bei PHP Entwicklungen, über die man nur den Kopf schütteln kann:

• Mit PHP 5.3.0 wurden Namespaces eingeführt. OK. Aber warum zum Henker musste man ausgerechnet den Backslash, also \ als Trenner zwischen Namespace und Klassennamen nehmen? Das werde ich nie begreifen. Es stinkt förmlich nach Problemen.
  Praktischerweise führt diese Entscheidung dazu, dass die meisten autoload-Mechanismen, die z.B. Klassenbenennungen nach dem PEAR- bzw. Zend Framework-Schema behandeln, unter Windows ohne Probleme auch damit zurechtkommen, wenn der Namespace eine eigene Verzeichnisebene bildet. Was vermutlich die Regel sein dürfte. Z.B. Foo\Oberklasse_Unterklasse wird korrekt abgebildet auf Foo\Oberklasse\Unterklasse.php. Übrigens: Auch wenn auf Foo\Oberklasse/Unterklasse.php abgebildet wird - der zweite Schrägstrich also ein gewöhnlicher ist, funktioniert dies bei Windows. Aber eben nur bei Windows. Auf *X-Systemen, die für gewöhnlich nicht mit \ als Verzeichnistrenner zurechtkommen, müssen autoload-Mechanismen zur Berücksichtigung von Namespaces abgeändert werden. So wurden Portabilitätsprobleme im wahrsten Sinne des Wortes "vorprogrammiert".
• Eigentlich sollte man, solange man den PEAR- bzw. Zend Framework-Konventionen zur Benennung von Klassendateinamen folgt, seit PHP 5.1.2 ganz auf einen selbstgeschriebenen autoload-Mechanismus verzichten können, da spl_autoload() als Default-Implementierung dafür zur Verfügung steht. Nun steht bei der entsprechenden Dokumentation im PHP Manual:  "By default it checks all include paths to contain filenames built up by the lowercase class name appended by the filename extensions .inc and .php." Moment! "lowercase class name"? Aber PEAR und Zend Framework, und alle die sich an deren Benennungskonvention halten, benutzen doch einen Großbuchstaben als jeweils erstes Zeichen in der Klassenhierarchie! Und das eben auch beim Verzeichnis- bzw. Dateinamen! OK, das ist bei Windows kein Problem. Denn auch Dateien die nicht dem Schema mit "lower class names" folgen, werden dort gefunden. Aber nicht auf *X-Maschinen. Dort wird im Dateisystem ja zwischen Groß- und Kleinschreibung unterschieden. Autsch!! Wer der PEAR- / Zend Framework-Benennungskonvention folgt, was eindeutig die am weitesten verbreitete Benennungskonvention ist, kann die schnelle Default-Implementierung also nicht benutzen, wenn alles portabel bleiben soll. Dieser "Feature-Bug" ist ohne Frage ein Sockenschuss der Güteklasse 1A!

Das soll an Informationen zu dieser Thematik erst einmal reichen. Im Prinzip gäbe es noch reichlich darüber zu schreiben, aber ich verweise auf die folgenden Links:

• What I don't like about PHP sowie die weiterführenden Links auf dieser Seite
• Coding Horror: PHP Sucks, But It Doesn't Matter
• Über PHP und den Rest

Wenn also PHP und/oder MySQL so schlecht sind, warum biete ich dann Dienstleistungen auf diesem Gebiet an?

Es gibt eben auch gute Gründe für PHP und/oder MySQL:

• Der hohe Grad der Verbreitung bedeutet eben auch, dass man sowohl bei Recherchen zur Lösungen von Problemen, als auch bei Skripten und Bibliotheken, CMS usw. eine Riesenauswahl hat, die so wohl einmalig ist.
• Kunden gehen ein begrenztes Risiko ein, wenn Sie eine Webanwendung mit PHP und/oder MySQL erstellen lassen, da es deutlich einfacher ist, dafür andere Entwickler zu finden, falls die Zusammenarbeit mit einem Entwickler oder Firma nicht so gut klappt. Allerdings ist dann auch zu wünschen, dass der Quellcode gewissen Mindestansprüchen genügt, damit so ein Wechsel auch relativ problemlos von statten gehen kann.
• Die Alternativen sind auch nicht durchweg ohne Probleme. Ich habe daher vor, auch anderen Umgebungen hier auf den Zahn zu fühlen.