Verständnisproblem mit Funktion in_array

[Timo "God's Boss" Reitz]

Ich kann nicht feststellen, dass die Sprache schlecht ist.
Und ich würde mich mit dieser Äußerung auch zurückhalten, bis ich eine bessere erfunden hätte oder aber wenigstens genau die "schlechten Stellen" benennen könnte nebst meiner Vorschläge für bessere Alternativen.

"'abcdefg' ist in [0, 1, 2] enthalten" ist bereits eine solche schlechte Stelle, verursacht durch die implizite Umwandlung. Bene wurde offenkundig völlig überrascht. Das Beispiel "a gleich b, b gleich c, aber a ungleich c", das in PHP möglich ist, habe ich auch schon genannt.
Und ich habe noch eine ganze Reihe anderer Probleme mit PHP:

• Zwar besitzt PHP inzwischen eine anständige Unterstützung für Objektorientierung, aber große Teile der API sind immer noch nicht objektorientiert. Arrays und Strings sind beispielsweise keine Objekte.
• Undurchsichtige Funktionsbenennungen: str_split vs. strcmp (mit Unterstrich und ohne), strlen vs. substr ('str' vorn und hinten)
• Völlig überdimensioniert: Wenn ich mir die ganzen Array- und String-Funktionen anschaue, wird mir übel. Das hätte man mit viel weniger lösen können.
  Insgesamt merkt man der Sprache ihre Geschichte einfach an.

Die automatische Typumwandlung in PHP finde ich auch nicht immer gut, schlimmer finde ich aber die iplizite Deklaration von Variablen. Gäbe es die nicht, würden viele Sicherheitslücken von selber verschwinden. Es wären aber auch solche Dinge wie
  while( $_rec = mysql_fetch_assoc($res) )
  {
      $_table[] = $_rec;
  }
nicht möglich, ohne wieder eine Ausnahme zuzulassen.

array_push($_table, $_rec); eventuell?

Man muss also überlegen, an welchen Stellen man ein striktere Handhabung haben will und an welchen sie lästig wäre.
Vielleicht führen die PHP-Entwickler ja einen Schalter "strikt_vars" ein, mit dem die grundsätzliche Deklaration von Variablen (also nicht deren Dimension, sondern "nur" deren Existenz und Grundtyp) zur Pflicht wird. Meisnt Du, dass wir eine genügend fundierte Anforderung dafür formulieren könnten/sollten?

register_globals ist der Schalter, der für die Sicherheitslücke verantwortlich ist, standardmäßig ist das seit Version 4.2.0 auf 'aus' (kann aber natürlich aktiviert werden in der entsprechenden Konfigurationsdatei) und ist seit 6.0.0 verschwunden. Undeklarierte Variablen können allerdings weiter genutzt werden, einen Schalter dagegen habe ich nicht gefunden.