OOP: Aufteilung der Aufgaben innerhalb einer Anwendung

[dedlfix]

Hi!

Mich ärgert z.B. immer wieder, dass es in PHP eine ganze Menge Funktionen nur für Arrays oder Strings gibt. Warum sind die nicht als Methoden angelegt? z.B. count(). Warum macht man so ein iniSet/iniGet- Geschwuchtel, statt $PHP kurzerhand als wunderbares Objekt zu behandeln in dem auch so Sachen wie ob_get_contents(), ob_end_flush(), ob_end_clean(), ob_implicit_flush(), ob_gzhandler(), ob_iconv_handler(),  mb_output_handler() und ob_tidyhandler() als Methode oder Eigenschaft angelegt sind?

Würdest du das machen inklusive all der Konsequenzen, die eine Änderung zum jetzigen Zeitpunkt hat? PHP war nicht als OO-Sprache geplant. Das kam erst in Version 4 hinzu. Deinen Wunsch zu erfüllen würde entweder bedeuten, für nahezu alles eine zweite Schnittstelle zu erstellen und dann für alles eine zwei Schnittstelle zu pflegen. Oder aber man entfernt den herkömmlichen Weg zugunsten einer reinen OOP, was bedeutet, dass quasi alle Scripte neu geschreiben werden müssen, wenn du mit der neuen OOP-PHP-Version weiterarbeiten willst. Diejenigen, die heute schon OOP so weit wie möglich nutzen, müssen auch angefasst werden, weil auch sie garantiert an irgendwelchen Stellen Funktionsaufrufe drinhaben.

Dito Datenbanken. [...] aber warum kein Objekt mit dem man etwa wie folgt umgehen kann oder, noch besser, muss:

Das gibt es ja, aber als Option.

Wäre es an dem, dass PHP konsequenter wäre, dann würde wahrscheinlich vielen der objektorientierte Ansatz auch besser gefallen. Aber so ist PHP zumindest anfangs offensichtlich als prozedurale Sprache entwickelt worden - und daran, inklusive der resultierenden Macken, hält man gerne fest.

Wie gesagt, nicht nur offensichtlich sondern ausschließlich. Das Umschwenken auf reine OOP käme einem Neuanfang gleich.

Lo!