Ich arbeite schon länger an einer "Automatisierung" für die Seitenerstellung für den konkurrierenden, verbindungslosen Betrieb. Du glaubst wahrscheinlich nicht, dass ich mit der Original OOP von PHP bereits die gesteckte Speichergrenze gekillt habe, mit meiner prozeduralen Programmierung unter Nutzung von "Array of Functions" aber erst ca. 3/5 erreicht habe, bei gleichem Funktionsumfang.
ich kann dir leider nicht folgen.
auch ich beschäftige mich schon seit jahren mit der 'richtigen' arbeitsweise von php. aber ich komme immer wieder auf objektstrukturen zurück. etwas besseres gibts unterm strich nicht.
Auch im Zeitalter von Gigabyte-RAM sollte man nicht fahrlässig werden.
wer braucht denn soviel speicher um eine seite aufzubauen ????
Das ganze Konzept "PHP Scripting" oder "PERL Scripting" ...usw ist von der Auslegung her schon ein Objektmodell. Wenn ,man da nun noch ein weiteres Objektmodell einpflanzt, könnte es sein, dass man das Rad viermal erfindet.
hier sehe ich keinen zusammenhang. php ist vom urgedanken her eine 'dynamisierung' von statischen seiten. hierbei werden teile der seite variabel gemacht, indem dort php benutzt wird. deshalb sieht der seitenquelltext auch idr. katastrophal aus und ist kaum lesbar.
es geht aber auch anders, wenn man programmlogik und darstellung trennt. meine programmlogik erstellt eine objektstruktur, welche mit dem von dir erwähnten objektmodell nichts zu tun hat, und dies auch nicht neu erfindet.