nicht angemeldet
Hellihello
Ich habe zudem immer noch den Eindruck, dass OOP oft nur betrieben wird,
weil sie "chique" ist, und "normale Menschen" sie nicht so leicht
verstehen... Alle OOP-Konzepte, die ich bisher kennengelernt habe, sind
auch nur Bastelkisten, Java vielleicht gerade mal ausgenommen.
So eine Aussage findet man auch nur bei self_html_... echt klasse das..
Meinen Eindruck trifft das überhaupt nicht. PHP, 1995 von Rasmus Lerdorf entwickelt, wurde von Andi Gutmans und Zeev Suraski (Zend-Technolgies) weiterentwickelt. Erst vor vier Jahren erschien die 5er Verion. Vor drei Jahren wurde mit der Entwicklung des Zend-Frameworks begonnen, was auf der OOP-Funktionalität (u.a. mit Interzeptormethoden) und "spl" (register_autoload, Iteratoren(?)) basiert.
Zu dem Zeitpunkt existierte Ruby on Rails bereits. Die Entwickler vom Zend-Framework verfolgen da wohl eine anderen "Vision". RoRs "Convention over Configuration" eben nicht ganz so strikt. Die Iteratoren, als Kern der "spl", sollen ja wohl sowas wie einen standardisierten Zugriff auf eine Datenstruktur haben, unabhängig von ihrer Quelle, oder? Keine "while(get_next_line/result())" mehr, sondern nur "foreach". Um verschachtelte Strukturen rekursiv zu durchlaufen wird dann zB. wohl die aktuelle Tiefe ->getDepth() mitgegeben. Ich finde es durchaus abstrakt, das Einbauen der korrekten <li> und <ul> war auch eher trial-and-error-driven.
Aber dass die über 12-jährige ja doch recht konsequente fortschreitende Entwicklung von PHP Dinge aus Gründen des "chick"s hervorbringen sollte, übersteigt mein Vorstellungsvermögen. Eher sowas wie: "Mit den Iteratoren sollte dies und jenes erreicht werden, haben die "User" aber nicht angenommen." Oder: "hat sich gezeigt, dass das anders besser lösbar ist". Der Versuch ist ja wohl, bei den Iteratoren der "spl" wie auch beim "FW", ein grundlegendes Modell anzubieten, dass genug Konventionen (u.a. auch Definition von "best practices" im ZendFW) bietet, um nach einheitlichen Grundmustern (und somit verständlich für andere sowie effizient) zu coden, auf der anderen Seite aber ausreichend Flexibilität, also den absichtlichen Verzicht auf gewisse Rahmen, die Ruby-on-Rails steckt.
Dank und Gruß,