Quote

Warum ich nicht freiwillig PHP einsetze!

3000++ Builtin-Functions
es gibt für beinahe alles eine funktion, was unweigerlich dazu führte, dass viele funktionen sich nur marginal unterscheiden. scheinbar wurden wahllos neue funktionen hinzugefügt, wann immer jemand eine vorhande funktion nicht fand und die dokumentation nicht zur hand war. es bleibt abzuwarten, wann es eine funktion guestbook() gibt, die ein komplettes gästebuch implementiert. Eine stärkere Modularisierung würde das ganze übersichtlicher machen.

kein herstellerunabhängiges datenbankinterface
für jede datenbank, für die PHP eingebaute funktionen hat, gibt es ein eigenes set an funktionen. um also datenbankunabhängig zu entwickeln, muss man wiederum eine eigene abstraktion von diesen funktionen schreiben, abhilfe schafft (wie so oft) eine kopie eines bekannten aus der perl-entwicklung: <a href="http://freshmeat.net/projects/php-dbi/" target="_blank">DBI</a>. Allerdings hat auch die Nachteile, sie unterstützt zwar die von DBI bekannten Platzhalter mit entsprechendem auto-quoting, hat aber zB keine Möglichkeit, queries mit zu compilieren mit internem caching für höhere geschwindigkeit bei mehrfacher ausführung eines statements mit verschiedenen werten.

inkonsistente builtin-namenskonvention
die benennung der builtinfunctions scheint je nach entwickler und tagesform verschieden zu sein, es gibt keine durchgehende regel. mal werden die abegkürzten wörter aneinandergehängt, wie bei <i>strlen()</i>, mal werden teile abgekürzt und andere nicht und das ganze durch unterstriche verdeutlicht, zB <i>str_replace</i> oder <i>preg_replace</i>. dann gibt es die namen ohne abkürzungen, und auch wieder in beiden varianten, durch unterstriche getrennt wie <i>is_string</i> und ungetrennt wie <i>stripslashes</i>. das macht es teilweise schwierig, die richtigen funktionen zu finden und ist überflüssig, es scheint, als hätten viele entwickler vollkommen unkoordiniert zusammengearbeitet.

keine lexikalischen variablen / dafür merkwürdige globals
lexikalische variablen sind variablen, die ihre gültigkeit nur im aktuellen block haben und sie anschließend wieder verlieren. dadurch ist es unwichtig, ob eine variable im übergeordneten block bereits existiert - wenn sie lexikalisch im untergeordneten blcok definiert wird, ist sie in diesem von der vorherigen variable abgekoppelt. man kann sie nach belieben verändern und sobald sie "out of scope" (sobald der block beendet ist) geht, ist die vorher gültige variable wieder intakt. das wäre ein schönes feature, da nicht alle variablen global sein müssen. allgemein sind die globals merkwürdig, da sie zwar im script und in allen includeten dateien global gültig sind, nicht jedoch in subroutinen. dort wiederum können sie aber mit <i>global</i> importiert werden.

register globals
don't get me started. register globals von anfang an grober unsinn. ein PHP-Script bekommt per GET, POST, in einem Cookie oder aus einer vorher gesetzten Session Daten übermittelt und PHP importiert diese automatisch als globale Variablen. Das ist nicht nur sicherheitstechnisch äußerst bedenklich, es macht auch die Programmierung teilweise schwierig, besonders was Sessiondaten angeht. Hierbei werden die globalen Variablen wiederum als eine art referenz angelegt, sodass eine veränderung der automatisch importierten daten auch eine veränderung der in der session gespeicherten daten zur folge hat. das ist ärgerlich, da somit einige variablennamen unbenutzbar werden, da lexikalische variablen ja nicht vorhanden sind (s.o.). register globals ist eine funktion, die in der php.ini, der globalen konfigurationsdatei aktiviert oder deaktiviert wird, dementsprechend lässt sie sich in einem script nicht deaktivieren.

keine kontextsensitiven vergleichsoperatoren
PHP kann zwar leicht zwischen verschiedenen skalaren datentypen wechseln, hat aber gleichzeitig nur einen vergleichsoperator. den wiederum kann man dann erweitern, indem man <i>===</i> benutzt, um zu vergleichen, ob zwei werte gleich und vom gleichen typ sind, ansonsten weiß PHP nicht, wie es vergleichen soll - wenn "string" und 0 verglichen werden sollen, ist es ein string-vergleich oder ein numerischer vergleich? würde "string" zu einer zahl umgewandelt, würde er zur 0 werden und der vergleich ergäbe true, ein string-vergleich schlüge fehl. hier wäre etwas mehr kontrolle in form von auswahlmöglichkeit gut getan. es stellt sich die frage, warum man sich nicht auch hier an perl orientiert hat?

php.ini
In PHP wird die Konfiguration über eine globale Datei gesteuert. Das hat Vorteile, da man so gewisse Teile von PHP deaktivieren kann, wenn es aus Sicherheitsgründen gewünscht wird. Der eklatante Nachteil aber ist, dass dadurch gewisse Verhaltensweisen wie register globals (s.o.) nicht mehr für einzelne Scripte konfigurierbar sind. Es ergibt sich, dass man das Verhalten von PHP nicht vorhersagen kann, ohne die php.ini zu kennen. Ein Script kann auf einem Server funktionieren und auf einem anderen Server mit exakt der selben PHP-Version Probleme bereiten, ganz und gar abhängig von der php.ini.