Quo vadis PHP? - Was würdet ihr euch von PHP wünschen?

[Norbert Eder]

PS. wenn du mal wirklich schlimmen Code sehen willst, dann schau OSCommerce an

Danke, schau ich mir lieber nicht an ;-)

Na das war ja aber bis jetzt das Problem von PHP, du konntest nicht sauber programmieren, da OOP zwar in Ansätzen umgesetzt war, aber sobald du mit Objekten herumjongliert hast, wurde der Webserver an seine Grenzen getriefen. Performance-mäßig einfach grottenschlecht.

 

[Andreas Gaisbauer]

Ja, aber man kann auch prozedural sauber programmieren - oder findest allen ernstes z.B. alle in C geschriebenen sachen per se "unsauber"? Wenn ich PHP brauche, dann sind das meistens zwischen 10 und 20 eigene Funktionen - das kann ich durchaus noch ohne OOP übersichtlich halten. Ich behaupt jetzt mal, das PHP DIE Mainstreamsprache überhaupt ist. Ist klar das dann auch viele Leute das Schreiben anfangen die noch nie was von Datentypen oder Compilern gehört haben, und genau dann kommt furchtbarer Code raus (siehe oftmals PHP Forum). Das ist aber meiner Meinung nach nicht der Fehler von PHP sondern von den Anwendern.

 

[rootssw]

Ich weiß nicht woher der Irrglaube kommt, dass OOP alles so kompliziert macht, soviel Aufwand darstellt etc. OOP macht Software einfacher, strukturierter und wiederverwendbar.

Das OOP kompliziert sein muss, hab' ich ja garnicht behauptet bzw. behaupten wollen!
Aber es kann durchaus kompliziert werden!
Und wenn sich dann ein "Scriptkid" mit diesen komplizierteren Themen beschäftigen möchte, würde das PHP-Forum hier wohl aus allen Nähten platzen!

Wenn ich PHP brauche, dann sind das meistens zwischen 10 und 20 eigene Funktionen

Genau für diese Fälle ist PHP doch perfekt (jetzt bitte nicht darüber diskutieren, was "perfekt" bedeutet ) geeignet!
Wenn ich PHP-Scripts schreibe, bleibt die Anzahl der Zeilen eines Scripts doch meist unter 1000.
In eher seltenen Fällen werden es über 2000 Zeilen!
Und davon ist dann noch das Meiste HTML (wenn man nicht mit Templates arbeitet)!
Also wozu immer Klassen?!
Sicher OOP hat, und das ist auch unbestritten, große Vorteile!
Aber ich würde nur ungerne mit einem PHP arbeiten, dass erst noch alle Funktionen die ich brauche aus Klassen laden müsste!
Da hätte ich ja locker 5-10 Klassen für relativ gesehen kleine Scripte!
Und das Ganze dann evtl. per CGI - das muss nicht sein!
Die Ladezeiten wären unermesslich!

Außerdem muss das PHP ja auch für "Newbies" einigermaßen verständlich bleiben.
Denn wenn man z. B. ein Buch zu PHP durchlesen würde (wenn PHP denn z. B. eine ähnliche Struktur wie C++ aufweist), müsste sich ein gutes Buch natürlich auch den Anspruch erfüllen, möglichst detailiert in die Feinheiten von PHP einzugehen.
Dann kämme aber sehr oft der Satz "das kapier ich einfach nicht" zu Tage.
Und das dann zu erklären, was wohl die Aufgabe eines Forums wie diesem hier wäre, würde ewig viele posts kosten.

Dennoch finde ich, es wurde wirklich mal Zeit, dass die OOP in PHP deutlich verbessert wird!
Das scheint ja jetzt auch der Fall zu sein.

 

[Christian Fein]

*luft hol*

J2EE schneller als .NET:
Hmm .. zeich mal. Würd ich echt gern live sehen.

Laut letztem iX Benchmark sehr wohl.

Findest du in einer iX im letzten halben Jahr.
Du läufst einem Trugschluss in die Arme wenn du anhand des Vergleichs WindowsForms - Swing, deine Geschwindigkeitsüberlegungen anstellst.
WindowsForms greift auf Native Blblotheken zu, während Swing komplett
selbst gezeichnet wird.
Ansonsten sag ich dir das auch nochmal:
Mono ist nicht kompatibel zu .net. Grund ist das viele Dinge aufgrund von
Patenten seitens MS nicht implementiert werden darf.
Mono Unix wird kompatibel zu Mono Windows sein, aber nicht zu ms .net.
Wie sagte Steve Ballmer, es wird nur ein .net geben, und das ist von Microsoft,
dafür werden wir sorgen.
Mono wird spätestens dann wenn es eine Konkurrenz zu .net ist, mit der
Rechtsabteilung von MS zu tun bekommen, und dann wird sich noch mehr
ändern so das mit einem Plattformunabhängigen .net nicht zu rechnen ist.

Ad OOP
Ich denke ich kann _richtiges_ OOP. Schließlich besteht meine Aufgabe darin, Software zu designen und da gehts eigentlich nie wirklich um die GUI

Kein OOP für kleinere Projekte:
Ich weiß nicht woher der Irrglaube kommt, dass OOP alles so kompliziert macht, soviel Aufwand darstellt etc. OOP macht Software einfacher, strukturierter und wiederverwendbar. That is. Mir läufts kalt den Rücken runter wenn ich so einen Nudelcode á la PHP sehen muss (jup ich weiß, in der 5er ist ja alles anders, wird aber trotzdem keiner seinen Stil ändern).

Das sagt gar nichts, auch ich arbeite seid Jahren in der Branche, und habe auch Kontakt zu sehr guten Entwicklern.
Die Grundlagen von OOP sind türlich recht einfach zu verstehen, aber zur OOP gehört auch sauberes Umsetzen von MVC, die Anwendung von Modellen und und und

Bei der Gelegenheit würde ich mal dein PDF betreffend dem Singleton Pattern überarbeiten.
Du wirfst eine unnötige Exception, besser währe es den Construktor mit einem private Construktor zu überschreiben, und generiere einge Zugriffsmethode auf eine einzige
Instanz.
Vorteil ist das du den Konstruktor weiter für das nutzen kannst was er tun soll, und in ihm keine Pattern-logic vorhanden ist.

Na das war ja aber bis jetzt das Problem von PHP, du konntest nicht sauber programmieren, da OOP zwar in Ansätzen umgesetzt war, aber sobald du mit Objekten herumjongliert hast, wurde der Webserver an seine Grenzen getriefen. Performance-mäßig einfach grottenschlecht.

Ein guter Programmierer kann auch in PHP sauber programmieren. Genauso wie mann in C sauber, auch ohne OOP, programmieren kann.
OOP ist eine hilfe sauberes Design by Contract durchzuführen, der Weisheit letzter Schuss ist es aber nicht. Es stimmt das bei prozedualen Programmiersprachen ein sauberes Design schwierierger, aber nicht unmöglich ist.

 

[Norbert Eder]

Ist klar das dann auch viele Leute das Schreiben anfangen die noch nie was von Datentypen oder Compilern gehört haben, und genau dann kommt furchtbarer Code raus (siehe oftmals PHP Forum). Das ist aber meiner Meinung nach nicht der Fehler von PHP sondern von den Anwendern.

Eine Programmiersprache soll von vornherein das Schreiben von unsauberem Code verhindern.

.NET vs J2EE
WindowsForms und Swing hast Du in den Mund genommen. Davon sprach ich nicht. Wie ich schon erwähnt habe, beides hat seine Vorteile. Ich sag nur, dass J2EE nicht _prinzipiell_ schneller ist. Man muss nur wissen, was wo und wann eingesetzt wird.

iX-Test
Mag schon sein, aber wenn ich Teile einer Technologie heraus nehme und vergleiche, macht das noch keinen _allgemeinen_ Test aus.

Mein PDF - Singleton
Unfairer Angriff. LIES dort mal genauer und Du wirst sehen, dass es dabei um eine Einführung und nicht um eine Design-Meisterleistung geht. Leute die das lesen sollen es verstehen und anwenden können.

OOP der Weisheit letzter Schluß?
Habe ich auch nicht behauptet. Es macht vieles einfacher und ich wollte hervorheben, dass OOP die Codeverwaltung bzw. den Code an sich sauberer macht. Klar kann man in PHP auch sauber programmieren. PHP verleitet aber dazu, schnell ein paar Zeilen _irgendwie_ zu programmieren. Hauptsache es tut.

Mono
Jo, bei Mono gehen natürlich alle Aussagen auseinander. Jeder behauptet was anderes. Letzter Stand (und der ist von der CeBIT), wird Mono 1.0 bzw. 1.1 kompatibel sein. Sowie bei der zweiten Version (soll im Dezember kommen) .NET 2 unterstützen (sofern dieses im Sommer kommt und wirklich .NET 2 heißt und nicht 1.2, aber das wissens selber noch nicht so genau bei M$)

Scripts mit 2000 Zeilen
Sollte schwerstens vermieden werden. Denn 2000 Zeilen sind unübersichtlich. Vielleicht nicht für dich, aber es könnte gut sein, dass auch weitere Entwickler im Laufe der Zeit mit dem Teil arbeiten werden und daher ist Übersichtlichkeit wichtig.


;-)

mfG,
Nitro

PS: Sollte ich ein Argument nicht behandelt haben, bitte drauf aufmerksam machen, wollte nichts überspringen, kann aber mal vorkommen

 

[Christian Fein]

Eine Programmiersprache soll von vornherein das Schreiben von unsauberem Code verhindern.

.NET vs J2EE
WindowsForms und Swing hast Du in den Mund genommen. Davon sprach ich nicht. Wie ich schon erwähnt habe, beides hat seine Vorteile. Ich sag nur, dass J2EE nicht _prinzipiell_ schneller ist. Man muss nur wissen, was wo und wann eingesetzt wird.

Das kann ich dir unterschreiben. Nur sah es so aus als würdest du behaupten wollen das .net um einiges schneller als J2EE ist, und das ist definitiv nicht so.
Es gibt Studien die bezeugen das .net schneller ist: Auftraggeber Microsoft
Es gibt Studien die bezeugen das J2EE schneller ist: Auftraggeber Sun Microsystems,. IBM
Das zeigt mir nur das es sich um ein Kopf an Kopf rennen handelt.

iX-Test
Mag schon sein, aber wenn ich Teile einer Technologie heraus nehme und vergleiche, macht das noch keinen _allgemeinen_ Test aus.

Mein PDF - Singleton
Unfairer Angriff. LIES dort mal genauer und Du wirst sehen, dass es dabei um eine Einführung und nicht um eine Design-Meisterleistung geht. Leute die das lesen sollen es verstehen und anwenden können.

Seh das bitte nicht als Angriff. Aber es ist definitiv falsch implementiert.
Du tauscht einen Fehler zur Kompilierzeit gegen einen Fehler zur Laufzeit aus. Besser ist eindeutig wenn der Kompilier sich meldet und sacht: Du kannst diese Klasse so nicht instanzieren.
Ein weiterer nachteil ist der Overhead des Triggers und der zusätzlichen Exception.
Zumal dein Singleton leider auch keine Instanz zurückgibt, weshalb es eigentlich kein Singleton ist. Besser ist

class MyClass {
  private static MyClass myClass;
  private MyClass() { //initilisierung
  };
  public static MyClass getInstance() {
    if(myClass==null) 
          myClass = new MyClass();
    return myClass;
   }
}

OOP der Weisheit letzter Schluß?
Habe ich auch nicht behauptet. Es macht vieles einfacher und ich wollte hervorheben, dass OOP die Codeverwaltung bzw. den Code an sich sauberer macht. Klar kann man in PHP auch sauber programmieren. PHP verleitet aber dazu, schnell ein paar Zeilen _irgendwie_ zu programmieren. Hauptsache es tut.

Richtig, das unterschreib ich dir. Aber für mich ist das Einsatzgebiet von PHP auch auf die Dinge begrenzt in denen ein bischen Spagetthi nichts anrichtet.
Und wenn mann eben ein kleines Newsscript braucht, dann ist PHP eine gute Wahl, denn es ist ausreichend.

Mono
Jo, bei Mono gehen natürlich alle Aussagen auseinander. Jeder behauptet was anderes. Letzter Stand (und der ist von der CeBIT), wird Mono 1.0 bzw. 1.1 kompatibel sein. Sowie bei der zweiten Version (soll im Dezember kommen) .NET 2 unterstützen (sofern dieses im Sommer kommt und wirklich .NET 2 heißt und nicht 1.2, aber das wissens selber noch nicht so genau bei M$)

Es gibt Dinge bei .net die sind nicht standardisiert, und MS hat ein Patent darauf.
Solange eine geschichte Unsicher ist, und das ist mit Mono, sprechen wir nicht von
Kompatibilität.
Ich wünsche Mono da viel Glück, denn ich finde das Projekt gut, Konkurrenz kann
Java nur weiterhelfen, sehe aber dennoch recht schwarz.
In einer Produktivumgebung die Plattformunabhängig sein soll wird Mono erst dann
eine Wahl wenn mann sich gegen MS durchgesetzt hat.

Scripts mit 2000 Zeilen
Sollte schwerstens vermieden werden. Denn 2000 Zeilen sind unübersichtlich. Vielleicht nicht für dich, aber es könnte gut sein, dass auch weitere Entwickler im Laufe der Zeit mit dem Teil arbeiten werden und daher ist Übersichtlichkeit wichtig.

Wenn die 2000 Zeilen gut und sauber strukturiert sind, ist das auch für weitere Entwickler kein Problem.

 

[Norbert Eder]

Original geschrieben von Christian Fein

Das kann ich dir unterschreiben. Nur sah es so aus als würdest du behaupten wollen das .net um einiges schneller als J2EE ist, und das ist definitiv nicht so.
Es gibt Studien die bezeugen das .net schneller ist: Auftraggeber Microsoft
Es gibt Studien die bezeugen das J2EE schneller ist: Auftraggeber Sun Microsystems,. IBM
Das zeigt mir nur das es sich um ein Kopf an Kopf rennen handelt.

Nein, hab mich vielleicht falsch/unklar/whatever ausgedrückt. Jetzt hamma schon zwei Unterschriften

Original geschrieben von Christian Fein

Seh das bitte nicht als Angriff. Aber es ist definitiv falsch implementiert.
Du tauscht einen Fehler zur Kompilierzeit gegen einen Fehler zur Laufzeit aus. Besser ist eindeutig wenn der Kompilier sich meldet und sacht: Du kannst diese Klasse so nicht instanzieren.
Ein weiterer nachteil ist der Overhead des Triggers und der zusätzlichen Exception.
Zumal dein Singleton leider auch keine Instanz zurückgibt, weshalb es eigentlich kein Singleton ist. Besser ist

class MyClass {
  private static MyClass myClass;
  private MyClass() { //initilisierung
  };
  public static MyClass getInstance() {
    if(myClass==null) 
          myClass = new MyClass();
    return myClass;
   }
}

Der in meinem PDF angeführte Code beruht auf James W. Cooper (The Design Patterns Java Companion) und bildet einen Printer-Spool ab. Auf diesen bezogen ist der Singleton richtig.
Willst Du einen allgemeinen Singleton darstellen, stimme ich Deinem Code zu.

Original geschrieben von Christian Fein

Richtig, das unterschreib ich dir. Aber für mich ist das Einsatzgebiet von PHP auch auf die Dinge begrenzt in denen ein bischen Spagetthi nichts anrichtet.
Und wenn mann eben ein kleines Newsscript braucht, dann ist PHP eine gute Wahl, denn es ist ausreichend.

Für kleine Hacks ja. Aber sobalds aufwändiger wird, würde ich nicht mehr auf PHP zurückgreifen. Hab auch lange Zeit mit PHP gearbeitet, aber mittlerweile find ichs einfach nur mehr grausam.

Original geschrieben von Christian Fein

Es gibt Dinge bei .net die sind nicht standardisiert, und MS hat ein Patent darauf.
Solange eine geschichte Unsicher ist, und das ist mit Mono, sprechen wir nicht von
Kompatibilität.
Ich wünsche Mono da viel Glück, denn ich finde das Projekt gut, Konkurrenz kann
Java nur weiterhelfen, sehe aber dennoch recht schwarz.
In einer Produktivumgebung die Plattformunabhängig sein soll wird Mono erst dann
eine Wahl wenn mann sich gegen MS durchgesetzt hat.

Ja, stimme ich dir vollkommen zu - das stimmt schon so. Für einfache Dinge ist es allerdings eine Alternative. Findet Mono genügend Unterstützung, könnte dadurch schon ein wenig "Macht" entstehen, aber man wird sehen.

Aber man sieht ja auch bei Java, dass da Sun gewaltig drauf sitzt. Ist ja immerhin auch nicht alles OpenSource und einsehbar.

Original geschrieben von Christian Fein

Wenn die 2000 Zeilen gut und sauber strukturiert sind, ist das auch für weitere Entwickler kein Problem.

Mag durchaus sein. In jeder Designvorlesung wirst Du aber hören, dass keine derartigen Skripts/Klassen/whatever geschrieben werden sollten. Hat man sich auch mal an recht kleine, sauber programmierte Klassen gewöhnt, will man einfach kein 2000-Zeilen-Skript mehr sehen.

lG,
Nitro

 

[Christian Fein]

Original geschrieben von nitronic
Der in meinem PDF angeführte Code beruht auf James W. Cooper (The Design Patterns Java Companion) und bildet einen Printer-Spool ab. Auf diesen bezogen ist der Singleton richtig.
Willst Du einen allgemeinen Singleton darstellen, stimme ich Deinem Code zu.

Die Definition des Singleton ist das ein einziges Object instanziert wird, und mann
nur eine Referenz auf diese eine Instanz erhalten kann. Bei deiner Implementation
bekomme ich keine Instanz.
Es fällt mir zwar schwer Buchauthoren, die auch nicht unbekannt sind zu berichtigen,
aber was immer auch Cooper da implementiert hat ist kein Singleton.
Ich hab das Buch zuhause, werd da heute abend mal nachlesen was dies darstellen soll.

Original geschrieben von nitronic

Für kleine Hacks ja. Aber sobalds aufwändiger wird, würde ich nicht mehr auf PHP zurückgreifen. Hab auch lange Zeit mit PHP gearbeitet, aber mittlerweile find ichs einfach nur mehr grausam.

Auch das unterschreib ich. PHP macht mir auch kein Spass, aber es gibt Einsatzgebiete bei denen ich sowohl privat als auch beruflich darauf zurückgreif, weil
PHP einfach das Tool ist welches in diesem Einsatzgebiet am besten geeignet ist.

Original geschrieben von nitronic

Aber man sieht ja auch bei Java, dass da Sun gewaltig drauf sitzt. Ist ja immerhin auch nicht alles OpenSource und einsehbar.

Das ist nicht richtig. Jeder kann den JDK SourceCode bekommen, und ich hab ihn auch hier.
Also einzusehen ist alles, was du "im gegensatz zu OpenSource" nicht machen darfst, ist diesen Source zu verwenden um dein eigenes JDK zu implementieren.
Ausser natürlich du zahlst die recht deftigen Gebühren. Aber einsehbar ist der Code.

Original geschrieben von nitronic

Mag durchaus sein. In jeder Designvorlesung wirst Du aber hören, dass keine derartigen Skripts/Klassen/whatever geschrieben werden sollten. Hat man sich auch mal an recht kleine, sauber programmierte Klassen gewöhnt, will man einfach kein 2000-Zeilen-Skript mehr sehen.

Dazu eine kleine Geschichte aus meinem Berufsleben. Ich musste eine Applikation basierend auf Windows DNA, sprich ASP ActiveX-Componenten erweitern.
Die ursprüngliche Applikation wurde geschrieben von einem Diplominformatiker und Referrent bei einer recht bekannten Uni.
Diese Applikation hatte in 30 verschiedenen Dateien jeweils händisch die Datenbank verbindung aufgebaut, und war vom Design so verkorkst das sich die Erweiterrungskosten vervierfacht haben.

Klar es gibt einige Designrichtlinen, die Praxis aber zeigt , zwar nicht oft aber mannchmal, einen anderen Wert als die graue Designtheorie.
Wenn 2000 Zeilenscript in einer Situation, auch nach reichlicher überlegung angebracht ist, dann ist das angebracht.
Wobei wir nicht unbedingt von 2000 Zeilen in einer Datei reden sollten.

 

[Norbert Eder]

Ich hatte von 2000 Zeilen in einer Datei gesprochen, hat sich nämlich in der ursprünglichen Aussage so gelesen.

Das Buch gibts auch online, siehe:

The Design Patterns Java Companion ---> Seite 32 suchst Du

Praxis
Klar, die Praxis hat mir auch schon oft genug gezeigt, dass Theorie schön, aber manchmal nur schwer brauchbar ist. Ausgangspunkt waren aber, wie mein erster Satz schon sagt, dass ich es so verstanden habe, dass 2000 Zeilen in _einem_ Script vorhanden sind.

lG,
Nitro

 

[Christian Fein]

Der Unterschied zwischen dem SingletonPattern aus dem Buch und dem
anderen, das in dem Buch auch vorgestellt wird ist.

Bei dem ersten erhälst du nachdem du eine Instanz erzeugt hast, keine
weitere Instanz, und auch keine Referenz auf die 1. Instanz zurück.

Wohl eher selten angewandt, die Geschichte und kommt in der Form
wohl eher weniger vor.
Mir fällt mir jetzt auch kein Einsatzgebiet dieser Geschichte ein, das zweite
ist jedoch ziemlich häufig, z.b in der jdk, eingesetzt und auch ich nutz das
recht häufig.
Mal schauen ob bei A) sich mal ein Einsatzgebiet zeigt.