PHP 4 -> PHP 5

[Pit]

Hallo PHPler/INNEN,

ich hab' mich mit PHP 5 beschäftigt - u. ich werde für mein WCMS + Module MYSQLi u. einige neue OO-Features nutzen.

MYSQLi, da es performater ist.

Ob ich OO-Programmierung komplett neu schreibe, oder nur Teile, ich weiß nicht, ist bei mir auch 'n Zeitproblem.

Würd' mich interessieren, wie sieht es bei euren Webprojekten so aus ?

Pit

[Christoph Schnauß]

hallo,

ich werde für mein WCMS

Aha. Und was ist das, muß man das kennen?

• Module MYSQLi u. einige neue OO-Features

Aha. Und was ist das, muß man das kennen?

MYSQLi, da es performater ist.

Aha, und was bedeutet "performater", muß man das kennen?

Ob ich OO-Programmierung komplett neu schreibe, oder nur Teile, ich weiß nicht, ist bei mir auch 'n Zeitproblem.

Aha, und was bedeutet das, müssen "wir" über deine Zeitprobleme jetzt intensiver diskutieren?

Würd' mich interessieren, wie sieht es bei euren Webprojekten so aus ?

Aha. Und was passiert, wenn ich grade kein Webprojekt mit PHP in Arbeit habe, sondern mit einem komplexen JSP-Dings herumwurschteln muß? Kannst du dir vorstellen, daß es auch Projekte gibt, die völlig ohne PHP auskommen?

Grüße aus Berlin

Christoph S.

[Twilo]

Hallo,

[...]

Aha. Und was passiert, wenn ich grade kein Webprojekt mit PHP in Arbeit habe, sondern mit einem komplexen JSP-Dings herumwurschteln muß? Kannst du dir vorstellen, daß es auch Projekte gibt, die völlig ohne PHP auskommen?

Aha, und warum schreibst du jetzt das ganze?

Aha, wie gut dass er PHP-Leute angesprochen hat und du mit JSP kommst

Aha und tschüss

mfg
Twilo

[Christoph Schnauß]

hallo Twilo,

Aha, und warum schreibst du jetzt das ganze?

Weil du versäumt hast, irgendeine _konkrete_ Frage zu stellen. Es gibt ein paar klitzekleine Unterschiede zwischen PHP 4.x und PHP 5.x, das ist richtig. Mit OOP haben allerdings beide zu tun, je nachdem, wie geschickt du deine Scripts schreibst oder geschrieben hast.

Stell eine _konkrete_ Frage, an der deutlich wird, wo dir irgendein Unterschied zwischen den beiden PHP-Versionen aufgefallen ist. Gib das zugehörige Script an. Dann wird man diskutieren können.

Grüße aus Berlin

Christoph S.

[Twilo]

Hallo,

Aha, und warum schreibst du jetzt das ganze?

Weil du versäumt hast, irgendeine _konkrete_ Frage zu stellen. Es gibt ein paar klitzekleine Unterschiede zwischen PHP 4.x und PHP 5.x, das ist richtig. Mit OOP haben allerdings beide zu tun, je nachdem, wie geschickt du deine Scripts schreibst oder geschrieben hast.

Stell eine _konkrete_ Frage, an der deutlich wird, wo dir irgendein Unterschied zwischen den beiden PHP-Versionen aufgefallen ist. Gib das zugehörige Script an. Dann wird man diskutieren können.

dir ist sicherlich aufgefallen, dass der Antwortende eine andere Person ist, als der Fragenstellende, oder :)

mfg
Twilo

[Christoph Schnauß]

ups,

dir ist sicherlich aufgefallen, dass der Antwortende eine andere Person ist, als der Fragenstellende, oder :)

ja, 'tschulligung :-(

Meinst du denn, daß die geringe Hoffnung besteht, er könnte das auch gelesen haben?

zerknirschte Grüße aus Berlin

Christoph S.

[Twilo]

Hallo,

Meinst du denn, daß die geringe Hoffnung besteht, er könnte das auch gelesen haben?

da er auf andere Beiträge geantwortet hat, gehe ich mal davon aus, dass er das auch gelesen hat  ;)

zerknirschte Grüße aus Berlin

ab Dezember wohne ich in Berlin, wenn du ein ausgibst, verzeihe ich dir :-P

mfg
Twilo

[Christoph Schnauß]

morgens,

ab Dezember wohne ich in Berlin, wenn du ein ausgibst, verzeihe ich dir :-P

"ich muß weg"

Christoph S.

[Twilo]

Hallo,

ab Dezember wohne ich in Berlin, wenn du ein ausgibst, verzeihe ich dir :-P

"ich muß weg"

tztz ;)

mfg
Twilo

[Mark]

Hallo Christoph,

ich werde für mein WCMS

Aha. Und was ist das, muß man das kennen?

Nein, aber Web-Content-Manangement-System ist ein durchaus geläufiger Begriff.

• Module MYSQLi u. einige neue OO-Features

Aha. Und was ist das, muß man das kennen?

Nur wenn man sich mit PHP, MySQL und objektorientierter Programmierung beschäftigt. Sollte man dann jedenfalls. Vielleicht.

MYSQLi, da es performater ist.

Aha, und was bedeutet "performater", muß man das kennen?

Absolut ja.

Ob ich OO-Programmierung komplett neu schreibe, oder nur Teile, ich weiß nicht, ist bei mir auch 'n Zeitproblem.

Aha, und was bedeutet das, müssen "wir" über deine Zeitprobleme jetzt intensiver diskutieren?

Nein, er wollte nur zum Ausdruck bringen, dass er sich nicht sicher ist. Denke ich jedenfalls mal.

Würd' mich interessieren, wie sieht es bei euren Webprojekten so aus ?

Aha. Und was passiert, wenn ich grade kein Webprojekt mit PHP in Arbeit habe, sondern mit einem komplexen JSP-Dings herumwurschteln muß?

Dann ließt Du zukünftig am besten auch keine Threads die sich mit PHP beschäftigen.

Kannst du dir vorstellen, daß es auch Projekte gibt, die völlig ohne PHP auskommen?

Kann er bestimmt. Kannst Du Dir vorstellen, das Dein Posting ziemlich arrogant rüberkommt und nichts zu dem Thread beiträgt?

Gruß
Mark

[Christoph Schnauß]

hi,

Kannst Du Dir vorstellen, das Dein Posting ziemlich arrogant rüberkommt

Ja.

und nichts zu dem Thread beiträgt?

Nein.

Grüße aus Berlin

Christoph S.

[Mark]

hi,

Kannst Du Dir vorstellen, das Dein Posting ziemlich arrogant rüberkommt
Ja.

Das ist gut.

und nichts zu dem Thread beiträgt?
Nein.

Das ist schade - nein, traurig.

Gruß
Mark

[TomIRL]

Hallo Mark,

ich werde für mein WCMS

Aha. Und was ist das, muß man das kennen?
Nein, aber Web-Content-Manangement-System ist ein durchaus geläufiger Begriff.

Meinst Du?
Und was soll dann ein WCMS vone einem CMS und DMS unterscheiden?

• Module MYSQLi u. einige neue OO-Features

Aha. Und was ist das, muß man das kennen?
Nur wenn man sich mit PHP, MySQL und objektorientierter Programmierung beschäftigt. Sollte man dann jedenfalls. Vielleicht.

Du scheinst Dich nicht besonders mit OO Programmierung auszukennen..
PHP ist selbst in PHP5 keine wirklich Objektorientierte Sprache.

MYSQLi, da es performater ist.

Aha, und was bedeutet "performater", muß man das kennen?
Absolut ja.

Ja perfomater was soll das sein?

Kann er bestimmt. Kannst Du Dir vorstellen, das Dein Posting ziemlich arrogant rüberkommt und nichts zu dem Thread beiträgt?

Zunächst mal an die Nase fasse und zwar an die eigene.

TomIRL

[Mark]

Hallo Mark,

ich werde für mein WCMS

Aha. Und was ist das, muß man das kennen?
Nein, aber Web-Content-Manangement-System ist ein durchaus geläufiger Begriff.
Meinst Du?

Ja, ich denke schon. Zumindest, wenn man z.B. mal nach google't.

Und was soll dann ein WCMS vone einem CMS und DMS unterscheiden?

Das ist eine andere Sache.

• Module MYSQLi u. einige neue OO-Features

Aha. Und was ist das, muß man das kennen?
Nur wenn man sich mit PHP, MySQL und objektorientierter Programmierung beschäftigt. Sollte man dann jedenfalls. Vielleicht.

Du scheinst Dich nicht besonders mit OO Programmierung auszukennen..
PHP ist selbst in PHP5 keine wirklich Objektorientierte Sprache.

Gut das Du Fachkompetenz besitzt.
PHP5 ist durchaus eine Sprache mit Objektorientierter Erweiterung. Auch wenn die Objektorientierung nicht so vehement durchgesetzt ist, wie z.B. bei Smalltalk oder Java.

MYSQLi, da es performater ist.

Aha, und was bedeutet "performater", muß man das kennen?
Absolut ja.
Ja perfomater was soll das sein?

Performant lässt sich mit schnell übersetzen.

Mark

[Christoph Schnauß]

hallo TomIRL,

PHP ist selbst in PHP5 keine wirklich Objektorientierte Sprache.

_Das_ ist allerdings eine Auseinandersetzung resp. Debatte wert. Eine Sprache ist _an sich_ nicht objektorientiert. Wichtig ist jedoch, ob sie die Möglichkeit anbietet, Scripts objektorientiert zusammenzustellen, die dann der zuständige Interpreter auch auszuwerten vermag. Bei PHP ist das meines Wissens durchaus der Fall, aber du darfst mich gern eines Besseren belehren.

Es liegt also meines Wissens nicht an der "Sprache", sondern daran, was der "Scriptautor" selber von OOP versteht und wie er seine Scripts schreibt.

Grüße aus Berlin

Christoph S.

[Andreas Korthaus]

Hallo!

Du scheinst Dich nicht besonders mit OO Programmierung auszukennen..
PHP ist selbst in PHP5 keine wirklich Objektorientierte Sprache.

Das hat er weder behauptet, noch soll es bzw. muss es das sein um objektorientiert programmieren zu können.

Grüße
Andreas

[Johannes Zeller]

Hallo Tom,

Aha, und was bedeutet "performater", muß man das kennen?
Absolut ja.
Ja perfomater was soll das sein?

Auf den Rechtschreibfehlern anderen rumzuhacken zeugt meiner Meinung nach in 99% der Fälle von Argumentenarmut.

Schöne Grüße.

Johannes

[Tom]

Hello,

ich werde für mein WCMS

Aha. Und was ist das, muß man das kennen?
Nein, aber Web-Content-Manangement-System ist ein durchaus geläufiger Begriff.

Na dann...

Ich hatte es schon mit "Water Closet Maintenance Service" übersetzt.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Auge]

Hallo

Ich hatte es schon mit "Water Closet Maintenance Service" übersetzt.

Und das am heutigen (19.11.) Weltklotag. (siehe: Artikel des Berliner Kurier zum Thema)
Wo ich schon mal auf deren Seite bin, wir hatten vor einiger Zeit das Thema Markenschutz für DDR- und FDJ-Emblem. Zumindest die Marke für das DDR-Emblem wurde aufgehoben. (Die DDR ist wieder Volkseigentum im Berliner Kurier)

Tschö, Auge

[Pit]

Liebe Leute,

ich möchte gerne von PHPler/INNEN(!), die sich mit PHP 5(!) schon beschäftigt haben, wissen, wie es bei ihren Webprojekten so ausssieht ?

Schließlich lernt man aus den Erfahrungen, die manch eine/r schon mit PHP 5 gemacht hat, sehr viel.

Und weil nach Fragen gefragt wurde:

Stellt ihr um von PHP 4 auf PHP 5 ?
Wenn nein, warum ?
Wenn ja, was stellt ihr um, und warum ?
...

Pit

[Mark]

Stellt ihr um von PHP 4 auf PHP 5 ?

Ja, demnächst.
Aber nur wegen der deutlich einfacheren XML Implementation.
Von der reinen OO-Seite her, sind die neuen Erweiterungen für mich nicht so wichtig, da meine Anwendungen auch unter PHP4 schon größtenteils OO Programmiert sind. Es gibt zwar keine Destruktoren, aber ich kann auch ohne die leben, genauso wie ich den Zugriffsschutz der Methoden und Eigenschaften nicht unbedingt benötige, weil ich einziger Entwickler meiner Projekte bin und Zugriffsverletzungen so ausschließen kann.

Objektreferenzen kann ich auch mit PHP4 erzeugen und die try-catch Routinen vermisse ich auch nicht wirklich.

Aber die XML-Unterstützung ist schon echt gut.

Ein Umstieg lässt sich aber nicht mit richtig oder falsch beantworten. Hängt wie immer alles vom Einsatzzweck ab.

Gruß
Mark

[Pit]

Hallo Mark,

Aber nur wegen der deutlich einfacheren XML Implementation.

das ist interessant, um was dreht es sich denn bei dir ?

Bei mir hab' ich nur Teile des content xml-fähig,  wie z.B. alle Artikel,  hierzu hab' ich aber selber ein xml-Parser programmiert, die damalige XML Implementation von PHP 4 war mir zu kompliziert, und zu wenig performant.

Ach' und meine News sind auch per RSS bookmarkbar.

Pit

[Mark]

Aber nur wegen der deutlich einfacheren XML Implementation.

das ist interessant, um was dreht es sich denn bei dir ?

Um den Im- und Export von Adressdaten auf XML-Basis für eine Adressverwaltung in Form einer Webapplication.

Bei mir hab' ich nur Teile des content xml-fähig,  wie z.B. alle Artikel,  hierzu hab' ich aber selber ein xml-Parser programmiert, die damalige XML Implementation von PHP 4 war mir zu kompliziert, und zu wenig performant.

Und wie hast Du das gemacht? Reg-Ex? Oder mit ner Lib?

[Üit]

Um den Im- und Export von Adressdaten auf XML-Basis für eine Adressverwaltung in Form einer Webapplication.

Ich brauche nur Export ;-)

Sag' mal, wie willst du es denn machen, per SimpleXML oder per DOM ?

Wie ich das verstanden hab' kann man lesen u. schreiben mit SimpleXML ?

An wann nimmt man eigentlich DOM ?

Und wie hast Du das gemacht? Reg-Ex? Oder mit ner Lib?

Reg-EX(PCREs)

Pit

[Mark]

Sag' mal, wie willst du es denn machen, per SimpleXML oder per DOM ?

Ich denke ich werde es per DOM machen. Warum weiß ich auch noch nicht so ganz genau, aber ich denke deswegen, weil ich dann ähnlich auf die Objekte zugriefen kann, wie z.B. bei Javascript auch - DOM eben.
Aber es durchaus sein, dass ich erst hinterher feststelle, das SimpleXML doch die bessere Variante gewesen wäre. Mal schauen.

Wie ich das verstanden hab' kann man lesen u. schreiben mit SimpleXML ?

Kannst Du meines Wissens nach mit DOM auch.

An wann nimmt man eigentlich DOM ?

Ich glaube nicht, das sich das pauschalieren lässt.

Und wie hast Du das gemacht? Reg-Ex? Oder mit ner Lib?
Reg-EX(PCREs)

Ich stand auch vor der Wahl mich mit ner Lib (z.B. Perl) zu beschäftigen oder Rex-Ex. Habe mich dann aber für PHP5 entschieden ;-)

So, ich gehe nun pennen, morgen früh klingelt der Interpreter ähh, Wecker..

CU

[Pit]

Danke dir für die Infos.

Pit

[Andreas Korthaus]

Hallo!

Um den Im- und Export von Adressdaten auf XML-Basis für eine Adressverwaltung in Form einer Webapplication.

Ich brauche nur Export ;-)

Sag' mal, wie willst du es denn machen, per SimpleXML oder per DOM ?

Wenn Du XML komplett neu erzeugen willst, würde ich vermutlich [Link:http://pear.php.net/package/XML_Tree@title=PEAR::XML_Tree], oder inzwischen eher DOM (PHP5) nehmen. Bedenke dass DOM komplett neu geschrieben wurde, nicht mit der alten DOMXML-Extension verwechseln!

Wie ich das verstanden hab' kann man lesen u. schreiben mit SimpleXML ?

An wann nimmt man eigentlich DOM ?

Lies mal folgende Präsentation: http://talks.php.net/show/php5xml

Prinzipiell ist simplexml halt - wie der Name schon sagt - sehr einfach gehalten, und für das einfache lesen und manipulieren von XML gedacht. Irgendwann stößt man allerdings hier an seine Grenzen, dann benötigt man den Funktionsumfang von DOM. Den Unterschied siehst Du schon, wenn Du Dir die Anzahl der jeweiligen Funktionen ansiehst.

Sonst noch interessant:
http://talks.php.net/show/php5_intro
http://talks.php.net/show/migrating-ffm2004

Grüße
Andreas

[Andreas Korthaus]

Hallo!

Bei mir hab' ich nur Teile des content xml-fähig,  wie z.B. alle Artikel,  hierzu hab' ich aber selber ein xml-Parser programmiert, die damalige XML Implementation von PHP 4 war mir zu kompliziert,

Dann werf mal nen flüchtigen Blick auf simplexml: http://de2.php.net/simplexml ;-)

und zu wenig performant.

Ihr immer alle mit Eurer Performance ;-)
Hast Du denn überhaupt solche stark frequentierten Seiten wo das bisschen ins Gewicht fällt? Außerdem ist DOM in PHP5 Dank libxml2 schneller, vor allem simplexml.

Grüße
Andreas

[Christoph Schnauß]

hallo Pit,

ich möchte gerne von PHPler/INNEN(!), die sich mit PHP 5(!) schon beschäftigt haben, wissen, wie es bei ihren Webprojekten so ausssieht ?

Ich bin möglicherweise durchaus das, was du unter einem "PHPler" verstehst oder verstehen möchtest. Das heißt: ich habe sowohl mit PHP 4.x wie auch mit PHP 5.x bereits Scripts eingesetzt und "Projekte" entwickelt (meine ersten Scripts habe ich noch brav *.php3 genannt). PHP 5 bietet einige deutlich verbesserte "Features", auf die XML-Implementierung bist du ja bereits aufmerksam gemacht worden  -  und zu recht. Es gibt noch deutlich mehr Dinge, die eine Favorisierung von PHP 5.x belegen könnten.

Aber das eigentliche Problem liegt "tiefer". Man muß schauen, was die PHP-Entwickler _wirklich_ machen. Und das ist an einigen Stellen bedenklich. PHP ist im Gegensatz zu Perl (aus dem es ganz ursprünglich bei Rasmus Lerdam mal entwickelt wurde) immer noch nicht modular aufgebaut, Perl ist das dagegen inzwischen schon seit geraumer Weile. Kurzfristig macht das nix, weil die Engines in PHP (Zend ...) unglaublich schnell und für das Internet optimiert worden sind. Längerfristig wird sich das aber als _die_ Schwachstelle erweisen, weil der Interpreter selbst immer größer werden muß, wenn man bei dieser Logistik bleibt.

Stellt ihr um von PHP 4 auf PHP 5 ?
Wenn nein, warum ?
Wenn ja, was stellt ihr um, und warum ?

Das ist meines Erachtens Oberflächengeplätscher. Es kommt doch nicht auf das geniale Script an,das du gerade schreibst, sondern es kommt darauf an, was dein Provider installiert hat und dir zur Nutzung freigibt.

Grüße aus Berlin

Christoph S.

[Andreas Korthaus]

Hallo Christoph!

Aber das eigentliche Problem liegt "tiefer". Man muß schauen, was die PHP-Entwickler _wirklich_ machen. Und das ist an einigen Stellen bedenklich. PHP ist im Gegensatz zu Perl (aus dem es ganz ursprünglich bei Rasmus Lerdam mal entwickelt wurde) [...]

Nein, das war der mit dem Käse, der gute Mann heißt Lerdorf ;-)
Und dass PHP aus Perl entwickelt wurde wäre mir neu:

The initial unreleased version of PHP was mostly a C library
of common C functions I had written to be easily reusable from
one open source project to the next. I had a simple
state-machine-driven parser that picked tags out of HTML files
and called the back-end C functions I had written. This code
was initially released to the public as a package called
Personal Home Page Tools, and each tool in the package was
an example of how to use the system to solve a common problem
on a personal home page.

(http://www.oracle.com/technology/pub/articles/php_experts/rasmus_php.html)

[...] immer noch nicht modular aufgebaut, Perl ist das dagegen inzwischen schon seit geraumer Weile. Kurzfristig macht das nix, weil die Engines in PHP (Zend ...) unglaublich schnell und für das Internet optimiert worden sind. Längerfristig wird sich das aber als _die_ Schwachstelle erweisen, weil der Interpreter selbst immer größer werden muß, wenn man bei dieser Logistik bleibt.

Wobei es aber bereits Bestrebungen in diese Richtung gibt. Genau hierzu gibt es PEAR, und vor allem PECL. Viele Extensions wurden schon hierhin ausgelagert, um die Standarddistribution nicht unnötig aufzublähen, auf der anderen Seite werden neue Extensions, wie sqlite, PDO... hier entwickelt, bevor sie in die Standardistribution aufgenommen werden. Und ein Großteil der Extensions in PECL wird nie in die Standards-Distribution aufgenommen, dafür kann man solche Extensions sehr komfortable per

pear install EXTENSION

installieren. Ich weiß, ist nicht dasselbe wie bei Perl/CPAN, aber im Moment finde ich es eigentlich ganz gut so.

Außerdem ist nicht gesagt dass die Zend-Engine für immer der Haupt-PHP-Interpreter bleiben muss, siehe z.B: http://phplens.com/phpeverywhere/?q=node%2Fview%2F84

Es kommt doch nicht auf das geniale Script an,das du gerade schreibst, sondern es kommt darauf an, was dein Provider installiert hat und dir zur Nutzung freigibt.

Natürlich, aber wie oben gesagt haben zumindest alle großen Provider bei denen ich PHP-Scripte habe bereits die Möglichkeit, PHP5 zu nutzen.

Grüße
Andreas

[Christoph Schnauß]

hallo Andreas,

PHP ist im Gegensatz zu Perl (aus dem es ganz ursprünglich bei Rasmus Lerdam mal entwickelt wurde) [...]
Nein, das war der mit dem Käse, der gute Mann heißt Lerdorf ;-)

oh, peinlicher Verschreiber. Sowas aber auch.

Und dass PHP aus Perl entwickelt wurde wäre mir neu:
(http://www.oracle.com/technology/pub/articles/php_experts/rasmus_php.html)

Interessant. Diese Stelle kannte ich nicht, und jetzt bin ich verunsichert, weil ich bisher immer die Aussage "PHP ist der Nachfolger eines älteren Produktes, PHP/FI. PHP/FI wurde 1995 von Rasmus Lerdorf geschaffen. Ursprünglich war PHP/FI ein Set von Perl Skripten zur Erfassung der Zugriffe auf seinen Webauftritt. Er nannte dieses Set von Skripten 'Personal Home Page Tools'." aus dem PHP-Handbuch für richtig gehalten habe. Das steht da schon sehr lange drin, und ich habe diese Stelle auch hier im Forum schon mehrmals ohne Widerspruch zitiert.

[...] immer noch nicht modular aufgebaut
Wobei es aber bereits Bestrebungen in diese Richtung gibt. Genau hierzu gibt es PEAR, und vor allem PECL.

Richtig. Nur ist das nach meinem Eindruck zur Zeit noch nicht konsequent durchgehalten. Da muß man abwarten, wie es weitergeht.

Grüße aus Berlin

Christoph S.

[Andreas Korthaus]

Hi Christoph!

(http://www.oracle.com/technology/pub/articles/php_experts/rasmus_php.html)

Interessant. Diese Stelle kannte ich nicht, und jetzt bin ich verunsichert, weil ich bisher immer die Aussage "PHP ist der Nachfolger eines älteren Produktes, PHP/FI. PHP/FI wurde 1995 von Rasmus Lerdorf geschaffen. Ursprünglich war PHP/FI ein Set von Perl Skripten zur Erfassung der Zugriffe auf seinen Webauftritt. Er nannte dieses Set von Skripten 'Personal Home Page Tools'." aus dem PHP-Handbuch für richtig gehalten habe. Das steht da schon sehr lange drin, und ich habe diese Stelle auch hier im Forum schon mehrmals ohne Widerspruch zitiert.

Hm keine Ahnung, ich kenne den oben verlinkten Artikel selber noch nicht besonders lang ;-)
Ist auch schwer abzugrenzen, da es ja aus einer vermutlich langsam wachsenden  Bibliothek eines einzelnen entstanden ist.

[...] immer noch nicht modular aufgebaut
Wobei es aber bereits Bestrebungen in diese Richtung gibt. Genau hierzu gibt es PEAR, und vor allem PECL.

Richtig. Nur ist das nach meinem Eindruck zur Zeit noch nicht konsequent durchgehalten. Da muß man abwarten, wie es weitergeht.

So oft werden ja auch keine neuen Erweiterungen geschrieben. Ich habe in letzter Zeit sehr wohl das Gefühl dass dies eingehalten wird, in einigen Changelogs, selbst in PHP4 war schon zu lesen, dass selten benutzte Bibliotheken in PECL ausgelagert wurden, bei neuen Erweiterungen wird eigentlich grundsätzlich verlangt, dass sie erstmal in PECL entwickelt werden sollen. Dies gilt z.B. auch für die neue date_time Extension, die irgendwann mal für ordentlichen Datums-Support sorgen soll. Aber so modular wie Perl wird PHP wohl nie werden. Aber was konkret stört Dich an der jetzigen Situation? Ich sehe da eigentlich keine Probleme. Jeder hat bei der Installation und teilweise sogar bei der Laufzeit-Konfiguration die Möglichkeit, Erweiterungen einzubeziehen, oder eben nicht.

Grüße
Andreas

PS: grad gelesen bzgl. PDO: http://www.zend.com/zend/week/week210.php#Heading6

[Mark]

Aber was konkret stört Dich an der jetzigen Situation? Ich sehe da eigentlich keine Probleme. Jeder hat bei der Installation und teilweise sogar bei der Laufzeit-Konfiguration die Möglichkeit, Erweiterungen einzubeziehen, oder eben nicht.

Ein Problem sehe ich persönlich darin, das man als Entwickler nie genau weiß, was beim Kunden vorhanden ist.
So läuft man gefahr, irgendeine Funktion zu verwenden und bei der Kundeninstalltion stellt sich heraus, das dieser die Lib vielleicht gar nicht eingebunden hat - aus welchen Gründen auch immer.

Gruß
Mark

[Andreas Korthaus]

Hallo Mark!

Ein Problem sehe ich persönlich darin, das man als Entwickler nie genau weiß, was beim Kunden vorhanden ist.

Ja, aber hast Du das Problem nicht ebenso bei Perl? Es liegt halt im Ermessen des Hosters welche Erweiterungen dieser installiert. Wenn Du außergewöhnliche Erweiterungen benötigst, dann gibt das schonmal Probleme, aber auch bei Perl.

So läuft man gefahr, irgendeine Funktion zu verwenden und bei der Kundeninstalltion stellt sich heraus, das dieser die Lib vielleicht gar nicht eingebunden hat - aus welchen Gründen auch immer.

Manche Hoster installieren auch mal sowas, wenn man ganz lieb bittet ;-)
Es gibt halt unterschiedliche Prioritäten bei Projekten. Das Projekt kann so groß sein, dass die Kompatibilität mit Standard-Hostern vernachlässigbar ist, und oft ist es gerade umgekehrt. In dem Fall muss man halt auf exotische Erweiterungen verzichten. Aber PHP wird halt nicht nur für die Standard-Hoster entwickelt.

Grüße
Andreas

[Mark]

Ja, aber hast Du das Problem nicht ebenso bei Perl? Es liegt halt im Ermessen des Hosters welche Erweiterungen dieser installiert. Wenn Du außergewöhnliche Erweiterungen benötigst, dann gibt das schonmal Probleme, aber auch bei Perl.

Ja, sicher,das gilt für Perl genauso.

Die von mir favorisierte 'Endlösung' wäre allerdings eine ganz andere (Ich beziehe mich jetzt mal fu PHP, gilt analog dazu aber auch für Perl):

Man müsste von dem reinen Interpreter weg kommen.
Idealweise würde das so aussehen:
Ich entwickle das Script mit allen Erweiterungen die für das Projekt relevant sind. Dann kompiliere ich es fix und fertig, so das der Interpreter sozusagen nichts mehr zu tun bekommt. Der Server arbeitet also kein zu interpretierendes Script mehr ab, sondern greift auf ein fertig kompiliertes Programm zu.

Vorteile:
1. Performance
2. Modularisierung (eben auf der Entwicklerebene)
3. Portabilität

Nachteile:
mit fallen keine ein, außer das es das eben noch nicht gibt.

Ansatzweise wurde das schon von Zend mit dem encoder realisiert - aber eben nur ansatzweise.

Gruß
Mark

[Andreas Korthaus]

Hallo!

Man müsste von dem reinen Interpreter weg kommen.
Idealweise würde das so aussehen:
Ich entwickle das Script mit allen Erweiterungen die für das Projekt relevant sind. Dann kompiliere ich es fix und fertig, so das der Interpreter sozusagen nichts mehr zu tun bekommt. Der Server arbeitet also kein zu interpretierendes Script mehr ab, sondern greift auf ein fertig kompiliertes Programm zu.

Vorteile:

1. Performance

Ich habe gelesen (finde die Quelle leider nicht), dass es rein Performance-mäßig so viel nicht bringen würde - gegenüber mod_php/fcgi + opcode cache.

2. Modularisierung (eben auf der Entwicklerebene)

Aber stell Dir mal vor, Du hättest gerade mit PHP angefangen, und müsstest das dann erst mal kompilieren, evtl. sogar noch mit verschiedenen Flags... Außerdem wird die Entwicklung so langsamer, möglicherweise auch qualitativ schlechter weil man nicht mehr so schnell die Ergebnisse kontrollieren kann, Tests laufen lassen kann...

3. Portabilität

Du bekommst aber Probleme, dass Deine schön kompilierten Scripte auf einmal nicht mehr überall laufen. Möglicherweise schon nicht auf unterschiedlichen Unix/Linux-Versionen, aber in jedem Fall nicht gleichzeitig unter Windows und Linux. Und schon gar nicht auf unterschiedlichen Rechner-Architekturen! Oder weißt Du ob Provider XY Solaris, Linux, FreeBSD... als Betriebssystem einsetzt, und das auf einer sparc-, x86-, amd64-... Architektur?

Nachteile:
mit fallen keine ein,

mir schon ;-)
Neben den oben genannten, ich weiß auch nicht ob das ganze Sicherheitstechnisch problematisch ist, denn wer sagt dass die Executables alle "sauber" sind?

außer das es das eben noch nicht gibt.

doch, das gibts: http://www.roadsend.com/home/index.php?SMC=1&pageID=compiler

Ansatzweise wurde das schon von Zend mit dem encoder realisiert - aber eben nur ansatzweise.

Das ist ganz was anderes. Hiermit kannst Du nur Deine Scripte in ein sehr schwer zu entzifferndes Format übersetzen, was dann Dank eines Zend-Moduls vom Interpreter zur Laufzeit in PHP-Opcode umgewandelt werden kann. Somit kann niemand so ohne weiteres den Quellcode der Scripte lesen, auch wenn er die funktionierenden PHP-Dateien öffnen/lesen kann.

Grüße
Andreas

[Mark]

Vorteile:

1. Performance
   Ich habe gelesen (finde die Quelle leider nicht), dass es rein Performance-mäßig so viel nicht bringen würde - gegenüber mod_php/fcgi + opcode cache.

Hmm, vom rein theoretischen Standpunkt aus, müsste es schon was bringen, denn das Interpretieren benötigt ja auch eine gewisse Zeit.
Aber kann schon sein, das es soo viel nicht bringt.

2. Modularisierung (eben auf der Entwicklerebene)
   Aber stell Dir mal vor, Du hättest gerade mit PHP angefangen, und müsstest das dann erst mal kompilieren, evtl. sogar noch mit verschiedenen Flags... Außerdem wird die Entwicklung so langsamer, möglicherweise auch qualitativ schlechter weil man nicht mehr so schnell die Ergebnisse kontrollieren kann, Tests laufen lassen kann...

Naja, idealweise würde der Server ja selbst erkennen, ob das Script bereits kompiliert wurde oder nicht. Durch irgendein Schlüsselwort könnte man dem Server sagen, stop, hier gibts nichts mehr zu inpretieren. Und für den PHP-Einsteiger würde sich damit nichts ändern.

3. Portabilität
   Du bekommst aber Probleme, dass Deine schön kompilierten Scripte auf einmal nicht mehr überall laufen. Möglicherweise schon nicht auf unterschiedlichen Unix/Linux-Versionen, aber in jedem Fall nicht gleichzeitig unter Windows und Linux. Und schon gar nicht auf unterschiedlichen Rechner-Architekturen! Oder weißt Du ob Provider XY Solaris, Linux, FreeBSD... als Betriebssystem einsetzt, und das auf einer sparc-, x86-, amd64-... Architektur?

Kommt ganz drauf an, wie sowas realisiert würde. Ich denke da nur an die Java-VM. Wenn man eine Art Sandbox für kompilierten PHP Code basteln würde...

Nachteile:
mit fallen keine ein,
mir schon ;-)
Neben den oben genannten, ich weiß auch nicht ob das ganze Sicherheitstechnisch problematisch ist, denn wer sagt dass die Executables alle "sauber" sind?

Naja, sie werden genauso sauber oder unsauber sein, wie der Quelltext auch.

außer das es das eben noch nicht gibt.
doch, das gibts: http://www.roadsend.com/home/index.php?SMC=1&pageID=compiler

Interessant.

Ansatzweise wurde das schon von Zend mit dem encoder realisiert - aber eben nur ansatzweise.
Das ist ganz was anderes. Hiermit kannst Du nur Deine Scripte in ein sehr schwer zu entzifferndes Format übersetzen, was dann Dank eines Zend-Moduls vom Interpreter zur Laufzeit in PHP-Opcode umgewandelt werden kann. Somit kann niemand so ohne weiteres den Quellcode der Scripte lesen, auch wenn er die funktionierenden PHP-Dateien öffnen/lesen kann.

Dann hatte ich das bisher falsch verstanden. Dachte die Scripte würden 'vorkompiliert', daher auch der von Zend angebene Performancevorteil. Aber nur um Scripte gegen Einsicht zu schützen, ist das natürlich Unfug - IMHO

Gruß
Mark

[Andreas Korthaus]

Hallo!

Kommt ganz drauf an, wie sowas realisiert würde. Ich denke da nur an die Java-VM. Wenn man eine Art Sandbox für kompilierten PHP Code basteln würde...

PHP ist nicht Java ;-)
Die ZendEngine ist die VM die den PHP-Opcode ausführt, etwa vergleichbar dem Java Bytecode. Es gibt Opcode Caches (Zend Accelerator, PECL::APC...), die den Opcode der PHP-Scripte im RAM cachen, und somit Scripte nicht ständig neu geparst oder überhaupt geöffnet werden müssen.

Naja, idealweise würde der Server ja selbst erkennen, ob das Script bereits kompiliert wurde oder nicht. Durch irgendein Schlüsselwort könnte man dem Server sagen, stop, hier gibts nichts mehr zu inpretieren. Und für den PHP-Einsteiger würde sich damit nichts ändern.

Du kannst Dir ja mal Gedanken machen und den Entwicklern einen Vorschlag inkl. Patch + Beispiel unterbreiten ;-)

Neben den oben genannten, ich weiß auch nicht ob das ganze Sicherheitstechnisch problematisch ist, denn wer sagt dass die Executables alle "sauber" sind?
Naja, sie werden genauso sauber oder unsauber sein, wie der Quelltext auch.

Ich dachte Du meintest jetzt wirklich ausführbare Dateien, die keinen Interpreter brauchen.

[Zend Encoder]
Dann hatte ich das bisher falsch verstanden. Dachte die Scripte würden 'vorkompiliert', daher auch der von Zend angebene Performancevorteil.

Ich weiß nicht ob Zend das verspricht, ich glaube die versprechen Dir ein bisschen vom Zend Optimizer, aber dessen Effekt ist selbst mit Opcode-Cache marginal. Aber wenn Du einen Encoder verwendest, kannst Du meines Wissens nicht gleichzeitig einen Opcode-Cache verwenden, womit es am Ende deutlich langsamer wird.

Aber nur um Scripte gegen Einsicht zu schützen, ist das natürlich Unfug - IMHO

Kann auch Sinn machen, aber sicher nicht wenn es um Performance geht.

Grüße
Andreas

[Christoph Schnauß]

hi,

So modular wie Perl wird PHP wohl nie werden. Aber was konkret stört Dich an der jetzigen Situation?

Nichts. Man kann ja gut damit arbeiten. Und ich bin selbsr kein Entwickler von PHP-Bibliotheken. Trotzdem finde ich die Diskussion über den prinzipiellen Aufbau einer Sprache interessant. Es sieht so aus, als käme jede Sprache in ihrer Entwicklung an den Punkt, an dem es gar nicht mehr anders geht als mit einer Modularisierung.

Grüße aus Berlin

Christoph S.

[Andreas Korthaus]

Hallo!

Würd' mich interessieren, wie sieht es bei euren Webprojekten so aus ?

Naja, bis jetzt habe ich kaum was portiert, aber alles was ich inzwischen schreibe muss mit PHP 5 laufen, und bei einigen Projekten benutze ich auch schon PHP 5, z.B. https://forum.selfhtml.org/?t=94464&m=571806.

Performance ist da für mich allerdings das unwichtigste Argument. Dir ist bewusst dass mysqli für mysql-Versionen ab 4.1 gedacht ist? Das wird kaum ein Provider in absehbarer Zeit installieren (4.1 gilt ja erst seit wenigen Tagen als stabil), zumal der Geschwindigkeits-Vorteil auch nicht soo groß ist. Bedenke dass dies fast nur die Kommunikation betrifft! Auf der anderen Seite bietet mysqli ja noch an anderen Stellen für Performance-Verbesserungen, so wie prepared statements... wobei das wie gesagt alles noch ganz frisch ist, PostgreSQL z.B. kann dies und noch viel mehr schon seit vielen Jahren. Außerdem muss man hierfür seinen Code anders schreiben.
Und auch der Rest von PHP 5 ist nicht wirklich schneller als PHP 4. Dies wird sich angeblich mit PHP 5.1 Anfang 2005 ändern, denn hier wurde sehr viel Aufwand in Performance-Optimierung gesteckt, und die Entwickler sagen dass PHP 5.1 fast doppelt so schnell ist, wie PHP 4 - bin ich mal gespannt!
Ein interessanter Artikel von Andi Gutmans von Zend zur Zukunft von PHP: http://www.oracle.com/technology/pub/articles/php_experts/FutureofPHP.html

Der große Vorteil von mysqli ist wohl die neue API, mit der man die vielen neuen Features von MySQL 4(.1) auch wirklich nutzen kann. Da ich aber die meisten Anwendungen nicht speziell für eine Datenbank schreibe, sondern mit einer DB-Abstraktion, freue ich mich wenn es sowas endlich im Standardumfang von PHP gibt, nämlich PDO. Das kommt auch in 5.1. Außerdem kann man in diesem Fall zu spezielle Features sowieso nicht verwenden.

Was ich sehr gut finde ist die verbesserte XML-Unterstützung, und natürlich die ZE-Änderungen (neue OOP, Exceptions...). Kleinere (nicht ganz so wichtige) Seiten lasse ich bereits mit PHP5 laufen, und spiele hier und da man mit den neuen Featurs rum, aber in der nächsten Zeit werde ich wohl auch mal ein größeres Projekt umstellen, so dass ich nicht ständig noch PHP4 OOP schreiben muss, die ich eh irgendwann los sein will ;-)

Und zum Thema "PHP5 bei den Hostern" hatte ich kürzlich schon mal was geschrieben:
</archiv/2004/10/t92558/#m558419>, inzwischen gibts das bei noch mehr großen Hostern, einfach mal fragen.

Und wenn man selber PHP4 und PHP5 parallel laufen lassen will, findet man im Internet genügend Hinweise, z.B. http://www.sitepoint.com/blog-post-view.php?id=159852.

Grüße
Andreas

[Pit]

Danke für die ausführliche Antwort.

Viele interessante Infos.

Man merkt du bist mittendrin im Thema.

Pit

» Hast Du denn überhaupt solche stark frequentierten Seiten wo das bisschen ins Gewicht fällt?
ja, z.b. www.ihre-vorsorge.de

[Andreas Korthaus]

Hallo!

Man merkt du bist mittendrin im Thema.

Naja, so richtig steige ich erst ein, wenn ich das größere Projekt umstelle. Bisher lief jedenfalls alles sehr unproblematisch.

Hast Du denn überhaupt solche stark frequentierten Seiten wo das bisschen ins Gewicht fällt?
ja, z.b. www.ihre-vorsorge.de

Nett! Allerdings würde ich an Deiner Stelle lieber an anderen Stellen Last einsparen.

• die meisten Seiten könntest Du komplett statisch erzeugen, so dass Du nicht jedes .html durch den PHP-Parser schicken musst!

• Du könntest entsprechende HTTP-Header einsetzen, damit Clients bestimmte Dateien cachen

• Du sprachst von einem XML-Export von Adressen, ja? Bei wieviel % der Requests wird dieser benötigt?

• wenn Du ständig XML lesen muss, könnt man die Informationen evtl. in einer PHP-Datenstruktur, evtl. sogar im RAM cachen?

Du könntest mal folgende Artikel zum Thema lesen: http://aktuell.de.selfhtml.org/artikel/server/apachetuning/index.html
http://talks.php.net/show/perf-oscom4
http://phplens.com/phpeverywhere/tuning-apache-php

Viele Grüße
Andreas

[Pit]

Hallo Andreas,

danke für die Tipps und vor allem die Links !

• die meisten Seiten könntest Du komplett statisch erzeugen, so dass Du nicht jedes .html durch den PHP-Parser schicken musst!

Da die Website demnächst über den individuellen Linkweg des Surfers personalisiert werden soll, gehen rein statische Seiten nicht.
Habe deswegen ein Chache-Parser + RealtTime-Parser programmiert.

• Du sprachst von einem XML-Export von Adressen, ja? Bei wieviel % der Requests wird dieser benötigt?

Ich nicht, dass war Marks Baustelle ;-)

http://verein.de.selfhtml.org/aktuelles/aemter.htm
Langjähriges Developer-Mitglied, zuständig für PHP-Programmierung und Redaktionelles.

Da bin ich ja an den SelfHTML-PHP-Profi geraten ;-)

wenn ich das größere Projekt umstelle.

find' leider nichts im Netz;-)
Um was handelt es sich denn, bin neugierig ;-)

Viele Grüße Pit

[Andreas Korthaus]

Hi Pit!

• Du sprachst von einem XML-Export von Adressen, ja? Bei wieviel % der Requests wird dieser benötigt?
  Ich nicht, dass war Marks Baustelle ;-)

Oh je, hast Recht ;-)

http://verein.de.selfhtml.org/aktuelles/aemter.htm
Langjähriges Developer-Mitglied, zuständig für PHP-Programmierung und Redaktionelles.

Was zur Zeit aufgrund beruflicher Projekte leider etwas zu kurz kommt...

Da bin ich ja an den SelfHTML-PHP-Profi geraten ;-)

Och, hier gibts zum Glück genügend andere "PHP-Profis" ;-)

wenn ich das größere Projekt umstelle.
find' leider nichts im Netz ;-)

sollst Du auch nicht :)

Um was handelt es sich denn, bin neugierig ;-)

eine Software für den elektronischen Beschaffungs-Prozess (B2B).

Grüße
Andreas