PHP5

[Babba]

Hallo,
ich habe eine ganz simple Frage:
Was ist an PHP5 so neu?

MfG euer Babba

[FraFu]

Hallo!

Hallo,
ich habe eine ganz simple Frage:
Was ist an PHP5 so neu?

Vielleicht hilft dir das weiter:
http://at.php.net/manual/de/migration5.php

mfg
  frafu

[wahsaga]

hi,

ich habe eine ganz simple Frage:
Was ist an PHP5 so neu?

http://www.php.net/manual/de/migration5.php

gruß,
wahsaga

[Christopher]

Hallo,

http://www.php.net/ChangeLog-5.php

Die haben einiges an der Objektorientierung erweitert.
Jedoch kann man immer noch nicht von OOP sprechen, ohne
dabei die Augen zu verdrehen.
Der Ansatz ist einfach nicht ernst zu nehmen. Wichtige
Sachen wie Generics, Mehrfachvererbung, Typsicherheit,
Annotations, Singleton-Patterns*, bitwise enums, Operatoren-
ueberladung und und und fehlen gaenzlich.

MfG
Christopher

* oder gibt es das mitterweile?

[wahsaga]

hi,

Singleton-Patterns*
* oder gibt es das mitterweile?

http://www.php.net/manual/de/language.oop5.patterns.php

gruß,
wahsaga

[Christopher]

Hi,

Singleton-Patterns*
* oder gibt es das mitterweile?
http://www.php.net/manual/de/language.oop5.patterns.php

Oh, das ist ja Wahnsinn! ;-)
Aber die anderen von mir erwaehnten "Features" existieren
wohl immer noch nicht?

Danke.
Christopher

[hkl]

Hallo !

Bei<http://de.wikipedia.org/wiki/Viererbande_%28Softwareentwicklung%29@tile=Gamma et al.> wird der Kontruktor protected deklariert.
In dem Beispiel wird der Konstruktor private deklariert.

Das halte ich, zumindest fuer viele Anwendungen, fuer unguenstig und zwar aus folgendem Grund:

Unter C++ habe ich oft "Abstrakte Fabrik"- Muster verwandt und zwar unter Einsatz von Singletons. Gamma et al nennen konkrete Fabriken als Beispiel fuer Singletons.
Schoen, aber der Client soll die Schnittstelle der abstrakten Fabrik nutzen, also doch wohl auch um uebrhaupt eine Referenz auf die Fabrik zu erhalten.

Wenn man aber den Kontruktor der abstrakten Fabrik protected deklariert kann eine abgeleitete konkrete (Singleton-)Klasse ihn verwenden wenn der Mechanismus der Instanzzuweisung im Konstruktor (!) der abstrakten Klasse  passiert.

Das ist zugegebermassen ein etwas kurioses Konstrukt - eher ein "Nullaton" als ein Singleton :-) - aber es kapselt ganze Subsysteme weg.

Damit das fuer den Client voellig transparent ist, kann man die Instanz der konkreten Kindklasse ( unter C++ ) in der Implementierungsdatei zum Programmstart erzeugen.
Wenn man das moechte.

Sieht jemand einen technischen Grund warum der Konstruktor in dem PHP5-Beipiel private deklariert wird ?

Methodisch koennte man natuerlich einwenden, dass sonst das Singleton-Konzept verwaessert wuerde und man die Klasse gegen missbraeuchliche Vererbung schuetzen moechte, aber ich denke abstrakte Fabriken lassen sich gar nicht sinnvoll realisieren, oder ?

Zumal sich hierbei zur Laufzeit auch nur ein Exemplar genau einer Kindklasse in dieser Weise "verankern" kann.

Gruss

Holger

hi,

Singleton-Patterns*
* oder gibt es das mitterweile?

http://www.php.net/manual/de/language.oop5.patterns.php

gruß,
wahsaga

[dedlfix]

echo $begrüßung;

Wichtige Sachen wie Generics,

Braucht es das bei einer Sprache, die nicht streng typisiert ist?

Mehrfachvererbung,

Wie oft wird Mehrfachvererbung verwendet, zumindest in den Sprachen, die das können? Wieviele Sprachen unterstützen dies? Und warum soll ausgerechnet PHP damit umgehen können sollen?

Typsicherheit,

Braucht es das bei einer Sprache, die nicht streng typisiert ist?
Außerdem: Type Hinting

Annotations,

Wie könnte man das bei PHP und dem dafür vorgesehenen Einsatzgebiet gewinnbringend einsetzen?

Singleton-Patterns*,

Das ist keine Frage von OOP. Das Singleton-Pattern konnte man auch schon mit PHP 4 realisieren.

bitwise enums,

Braucht es das bei einer Sprache, die nicht streng typisiert ist?

Operatorenueberladung

Kann man das bei einer Sprache, die nicht streng typisiert ist, sinnvoll anwenden?

und und und

and, &, &&   :-)

echo "$verabschiedung $name";

[Christopher]

Hallo $begrüßung,

Generics,
Braucht es das bei einer Sprache, die nicht streng typisiert ist?

Welchen Sinn macht eine Liste - in PHP nennt ihr das ja
afaik Array - wenn man nicht weiß, mit welchen Inhalten sie befuellt ist?
Und jetzt sag nicht, dass sich der Programmierer darum zu
bemuehen hat. Denn externe Komponenten liegen ausserhalb des
Einwirkungsbereiches.

Mehrfachvererbung,
Wie oft wird Mehrfachvererbung verwendet, zumindest in den Sprachen, die
das können?

Das wird haeufiger verwendet als Du es Dir vorstellst. Spaetesten bei groesseren
Projekten, wie zB Frameworks, ist es doch eine erhebliche Komfortabilitäts-
Steigerung.

Wieviele Sprachen unterstützen dies? Und warum soll ausgerechnet
PHP damit umgehen können sollen?

"ausgerechnet PHP"..?? Was ist denn das fuer ein Einwand?

Typsicherheit,
Braucht es das bei einer Sprache, die nicht streng typisiert ist?

Genau das sagte ich ja, dass die Nicht-Typisierung ein sehr grosses, wenn nicht
sogar DAS Manko schlechthin darstellt.

Annotations,
Wie könnte man das bei PHP und dem dafür vorgesehenen Einsatzgebiet gewinnbringend einsetzen?

Oh, da gibt es viele.
Deprecated, Override, UnitTests, Debug purposes..
Man erkennt einer Methode ja noch nicht einmal an, ob sie eine Methode ueberschreibt
oder nicht.

Singleton-Patterns*,
Das ist keine Frage von OOP. Das Singleton-Pattern konnte man auch schon mit PHP 4 realisieren.

Mein Einwand war auf OOP bezogen. Aber wie wahsaga mich bereits korrigierte, gibt es das
ja mitterweile auch schon.

bitwise enums,
Braucht es das bei einer Sprache, die nicht streng typisiert ist?

Hae? Das hat doch rein _gar nichts_ mit Typisierung zu tun! Und ja, da braucht es.

Operatorenueberladung
Kann man das bei einer Sprache, die nicht streng typisiert ist, sinnvoll anwenden?

s.o.

Dein einziges Argument, welches Du erwaehnst, fuerwahr gleich sechs Mal, ist, dass
keine strenge Typisierung existiert. Und siehe da, Du nennst bereits das Hauptmerkmal
von PHP, warum ich sagte, dass es nicht ernst zu nehmen ist.

Gruesse aus Berlin,
Christopher

[Vinzenz Mai]

Hallo Christopher,

Dein einziges Argument, welches Du erwaehnst, fuerwahr gleich sechs Mal, ist, dass
keine strenge Typisierung existiert. Und siehe da, Du nennst bereits das Hauptmerkmal
von PHP, warum ich sagte, dass es nicht ernst zu nehmen ist.

[1]

... dafür wird PHP als Grundlage für sehr ernst zu nehmende Projekte wie zum Beispiel die Wikipedia genutzt :-)
Natürlich gilt auch für PHP, was ich bereits vor einiger Zeit zitierte.

Freundliche Grüße

Vinzenz

[1] Nach Deiner Logik müsste ich sagen, dass Du nicht ernst zu nehmen
    wärst - was meiner Meinung nach ein Fehlschluss wäre ;-)

[Christopher]

Guten Tag Vinzenz,

... dafür wird PHP als Grundlage für sehr ernst zu nehmende Projekte wie
zum Beispiel die Wikipedia genutzt :-)
Natürlich gilt auch für PHP, was ich bereits vor einiger Zeit zitierte.

Also ueber die Qualitaet von Wikipedia kann man wirklich streiten.

Hast Du dir die Quelltexte schon mal angeschaut? Ist nicht gerade so, wie man sich eine
ordentliche Projektstruktur vorstellt. "Historisch gewachsen" wuerden einige sagen. Doch
dieses Argument zieht bei grundlegender initialer Ueberlegung eigentlich nicht, naja, es
sollte zumindest nicht existieren..

Freundliche Grüße

Das gleiche von meiner Seite.

Christopher

[1] Nach Deiner Logik müsste ich sagen, dass Du nicht ernst zu nehmen
    wärst - was meiner Meinung nach ein Fehlschluss wäre ;-)

Ich verstehe nicht worauf Du hinaus moechtest. Weil ich keine Typisierung bin oder was? ;-)

[Vinzenz Mai]

Hallo Christopher,

... dafür wird PHP als Grundlage für sehr ernst zu nehmende Projekte wie
zum Beispiel die Wikipedia genutzt :-)
Natürlich gilt auch für PHP, was ich bereits vor einiger Zeit zitierte.
Also ueber die Qualitaet von Wikipedia kann man wirklich streiten.

ich halte die Wikipedia für ein ernst zu nehmendes Projekt. Ich bin froh, dass es sie gibt und nutze sie gerne. Das heißt noch lange nicht, dass Wikipedia Unfehlbarkeit zugestehe. Niemand ist unfehlbar.

Hast Du dir die Quelltexte schon mal angeschaut? Ist nicht gerade so, wie man sich eine
ordentliche Projektstruktur vorstellt. "Historisch gewachsen" wuerden einige sagen. Doch
dieses Argument zieht bei grundlegender initialer Ueberlegung eigentlich nicht, naja, es
sollte zumindest nicht existieren..

Die Qualität eines Quelltextes hat wenig mit der Ernsthaftigkeit eines Projektes zu tun - oder ob ein Projekt ernst zu nehmen ist.

Betriebssysteme wie Windows oder die verschiedenen *ix-Varianten sind ernst zu nehmen, da sie für ernst zu nehmende Aufgaben eingesetzt werden. Nein, das ist nicht die Argumentation mit den vielen Fliegen ...

[1] Nach Deiner Logik müsste ich sagen, dass Du nicht ernst zu nehmen
    wärst - was meiner Meinung nach ein Fehlschluss wäre ;-)
Ich verstehe nicht worauf Du hinaus moechtest. Weil ich keine Typisierung bin oder was? ;-)

Ich verstehe folgendes nicht: Du bewertest etwas mit "nicht ernst zu nehmen", weil es bestimmte Eigenschaften, die Du (und andere) für wichtig hältst, nicht besitzt. Ich halte das für sehr anmaßend. Weil Du deswegen meiner Meinung nach "ernst zu nehmende" Projekte als "nicht ernst zu nehmen" klassifizierst, fehlt Dir eine meiner Meinung nach wichtige Eigenschaft. Nach Deiner Logik wärst Du "nicht ernst zu nehmen".

Ich sehe das anders.

Freundliche Grüße

Vinzenz

[Christopher]

Guten Tag Vinzenz,

ich glaube Du hast mich ein wenig falsch verstanden, was das Thema
"ernst zu nehmen" angeht.
Meine initiale Aussage war, dass OOP unter PHP5 nicht richtig ernst
zu nehmen sei. OK, darueber kann man wieder streiten, aber in Anbetracht
moderner OOP ist das durchaus argumentativ begruendbar.

Was Wikipedia, oder andere grosse PHP-Projekte angeht, dazu habe
ich mich nicht geaeussert, dass diese nicht ernst zu nehmen seien.
Ich mag Wikipedia und habe auch respekt davor, was die Jungs auf
die Beine gestellt haben.
<subjektiv>
Nur finde ich zum einen den Code nicht wirklich gut und zum anderen
haette ich dafuer sicherlich eine andere Sprache gewaehlt. ;-)
</subjektiv>

Schoenen Tag noch,
Christopher

[Vinzenz Mai]

Hallo Christopher,

ich glaube Du hast mich ein wenig falsch verstanden, was das Thema
"ernst zu nehmen" angeht.

ich meine eher, Du hast Dich anders ausgedrückt, als Du es vielleicht meintest.

Meine initiale Aussage war, dass OOP unter PHP5 nicht richtig ernst
zu nehmen sei.

Ja, das habe ich Deinem ersten Posting so entnommen:

Die haben einiges an der Objektorientierung erweitert.
Jedoch kann man immer noch nicht von OOP sprechen, ohne
dabei die Augen zu verdrehen.
Der Ansatz ist einfach nicht ernst zu nehmen.

Aber, Du verallgemeinerst diese Aussage in Deinem dritten Posting über den OOP-Bereich hinaus auf die gesamte Sprache:

Dein einziges Argument, welches Du erwaehnst, fuerwahr gleich sechs Mal, ist, dass
keine strenge Typisierung existiert. Und siehe da, Du nennst bereits das Hauptmerkmal
von PHP, warum ich sagte, dass es nicht ernst zu nehmen ist.

Ich habe mir diesen Absatz mehrfach durchgelesen, bevor ich meine Antwort schrieb. Ich wollte ganz sicher gehen; doch eine Einschränkung im Sinne Deines ersten Postings war für mich nicht wahrnehmbar, nur die Verallgemeinerung von "unzureichender OOP" auf "nicht ernstzunehmende Sprache".

Freundliche Grüße

Vinzenz

[dedlfix]

echo $begrüßung;

Und warum soll ausgerechnet PHP damit umgehen können sollen?
"ausgerechnet PHP"..?? Was ist denn das fuer ein Einwand?

PHP wurde nicht zur Veranschaulichung moderner OOP im Informatik-Studium entwickelt, sondern für den konkreten Einsatzzweck, Webseiten serverseitig dynamisch gestalten zu können. Deswegen sehe ich es nicht ein, warum es sämtliche Features einer ausgewachsenen OOP-Sprache mitbringen sollte.

Typsicherheit,
Braucht es das bei einer Sprache, die nicht streng typisiert ist?
Genau das sagte ich ja, dass die Nicht-Typisierung ein sehr grosses, wenn nicht
sogar DAS Manko schlechthin darstellt.

Für den geplanten Anwendungsfall PHPs ist die Typsicherheit meist kein ausschlaggebendes KO-Kriterium. Wenn es für deine Zwecke eins ist, nur zu ...

Singleton-Patterns*,
Das ist keine Frage von OOP. Das Singleton-Pattern konnte man auch schon mit PHP 4 realisieren.
Mein Einwand war auf OOP bezogen. Aber wie wahsaga mich bereits korrigierte, gibt es das
ja mitterweile auch schon.

Diese Muster sind allgemeine Lösungswege und nicht an konkrete Implementierungen oder Programmierweisen gebunden. Deswegen spielt die OOP-Fähigkeit des Einsatzgebietes dafür keine Rolle.

bitwise enums,
Braucht es das bei einer Sprache, die nicht streng typisiert ist?
Hae? Das hat doch rein _gar nichts_ mit Typisierung zu tun! Und ja, da braucht es.

Was ist es dann, wenn nicht ein Typ, konkret ein Aufzählungstyp? (Kann ja sein, dass ich mir darunter grad was anderes vorstelle als du beabsichtigt hast.)

Kann man das bei einer Sprache, die nicht streng typisiert ist, sinnvoll anwenden?
Dein einziges Argument, welches Du erwaehnst, fuerwahr gleich sechs Mal, ist, dass
keine strenge Typisierung existiert. Und siehe da, Du nennst bereits das Hauptmerkmal
von PHP, warum ich sagte, dass es nicht ernst zu nehmen ist.

Warum verallgemeinerst du das und stellt es nicht nur als deine persönliche Meinung dar?
Es sei dir ja unbenommen, die eierlegende Wollmilchsau zu bevorzugen. Nur sind deshalb nicht gleich alle Nur-Hühner nicht ernst zu nehmen, wenn sie fürs Eierlegen ausreichen.

echo "$verabschiedung $name";

[Christopher]

Hallo $begrüßung,

PHP wurde nicht zur Veranschaulichung moderner OOP im Informatik-Studium entwickelt,
sondern für den konkreten Einsatzzweck, Webseiten serverseitig dynamisch gestalten
zu können. Deswegen sehe ich es nicht ein, warum es sämtliche Features einer
ausgewachsenen OOP-Sprache mitbringen sollte.

Das ist, wie Du mir unten selbst vorgeworfen hast, _deine_ Meinung.
Meine Aussage, dass es als OOP-Sprache nicht "ernst zu nehmen" ist, ist an dieser
Stelle berechtigt. Ich verstehe ja die Existenzberechtigung von PHP. Man kann
sehr schnell, und mit Disziplin auch relativ schoen, kleinere Projekte realisieren.
Des weiteren ist LAMP fast bei jedem Provider installiert. Das ist tatsaechlich ein
definitivert Vorteil von PHP.

Typsicherheit,
Braucht es das bei einer Sprache, die nicht streng typisiert ist?
Genau das sagte ich ja, dass die Nicht-Typisierung ein sehr grosses, wenn nicht
sogar DAS Manko schlechthin darstellt.
Für den geplanten Anwendungsfall PHPs ist die Typsicherheit meist kein ausschlaggebendes
KO-Kriterium. Wenn es für deine Zwecke eins ist, nur zu ...

Naja, in Bezug auf Sicherheit ist es schon nicht so schoen. ein typisches Beispiel: Man
schleift eine ID in der URL mit und moechte diese spaeter verwenden. Wer garantiert, dass
es tatsaechlich ein integer Wert ist und kein String oder Amount? Die bereits oben
erwaehnte Disziplin hilft hier natuerlich weiter (man hat ja mitterweile sein Bibliothek,
wuie zB isIntAndNotNull() oder so was). Aber jeden Typ manuell zu ueberpruefen ist
schon ein wenig nervenraubend..

bitwise enums,
Braucht es das bei einer Sprache, die nicht streng typisiert ist?
Hae? Das hat doch rein _gar nichts_ mit Typisierung zu tun! Und ja, da braucht es.
Was ist es dann, wenn nicht ein Typ, konkret ein Aufzählungstyp? (Kann ja sein, dass
ich mir darunter grad was anderes vorstelle als du beabsichtigt hast.)

Ich habe wohl ein wenig zu lakonisch geantwortet.
M.M.n. sind enums unersaetzlich. Denn es ist sehr muehsam den Anwendungsbereich haendisch
nachzuahmen. Man stelle sich vor, eine Kalkulationsmethode Methode bedarf einer Waehrung
als Parameter.
Beispeil enum:

  
public enum Currency {  
     USD,  
     EUR  
}  
public double Calculate(Currency cur)  
{  
 [..]  
}  

Bsp. manuell:

  
public double Calculate(string cur) {  
 if(cur=="USD") ...  
 if(cur=="EUR") ...  
}  

Oder man muss extra eine neue Klasse erstellen, die lediglich den Wert Currency beinhaltet
und dessen Setter-Methode - hier auch wieder manuell - ueberprueft, ob es eine gueltige
Waehrung ist oder nicht. Alles viel zu aufwaendig.

Enums sind ein wohl-definierte Werte, mit denen sich komfortabler arbeiten laesst. Es ist
quasi ein Garant fuer einen korrekten Wert.

Warum verallgemeinerst du das und stellt es nicht nur als deine persönliche Meinung dar?
Es sei dir ja unbenommen, die eierlegende Wollmilchsau zu bevorzugen. Nur sind deshalb nicht gleich alle Nur-Hühner nicht ernst zu nehmen, wenn sie fürs Eierlegen ausreichen.

OK, da gebe ich Dir recht. Es ist vllt. zu subjektiv, als dass ich es als allgemeines Kriterium
verwenden kann.

Gruesse aus Berlin,
Christopher

[dedlfix]

echo $begrüßung;

PHP wurde nicht zur Veranschaulichung moderner OOP im Informatik-Studium entwickelt,
sondern für den konkreten Einsatzzweck, Webseiten serverseitig dynamisch gestalten
zu können. Deswegen sehe ich es nicht ein, warum es sämtliche Features einer
ausgewachsenen OOP-Sprache mitbringen sollte.
Das ist, wie Du mir unten selbst vorgeworfen hast, _deine_ Meinung.

Der erste Teil bezog sich auf PHPs Geschichte. Der Rest ist meine daraus gezogene Meinung. OOP war am Anfang gar kein Kriterium, das kam erst nach und nach hinzu. Schon deshalb wird es ein Äpfel- und Birnenvergleich, wenn man es mit von vorn herein objektorientiert entwickelten Sprachen vergleicht.

Typsicherheit,
Naja, in Bezug auf Sicherheit ist es schon nicht so schoen. ein typisches Beispiel: Man
schleift eine ID in der URL mit und moechte diese spaeter verwenden. Wer garantiert, dass
es tatsaechlich ein integer Wert ist und kein String oder Amount?

Niemand. Werte, die über HTTP übertragen werden, also GET- und POST-Parameter, sind generell Strings und außerdem vom Client veränderbar. Du musst sie in jeder Sprache prüfen und ggf. nach Integer casten oder parsen, wenn du einen Integerwert haben möchtest. Das war nicht grade das beste Beispiel :-)

Ansonsten ist Typsicherheit schon was Feines. Da funktioniert wenigstens die Codevervollständigung ordentlich :-)

M.M.n. sind enums unersaetzlich. Denn es ist sehr muehsam den Anwendungsbereich haendisch
nachzuahmen. Man stelle sich vor, eine Kalkulationsmethode Methode bedarf einer Waehrung
als Parameter.
public enum Currency {
     USD,
     EUR
}

Dann ist dein Programm ziemlich eingeschränkt und muss, wenn eine neue Währung hinzukommt, im Quelltext erweitert werden. Meiner Meinung nach ist der Name der Währung unerheblich. Die zu einer Währung gehörigen Daten, wie Name, Umrechnungsfaktor, etc., kommen aus der Datenbank. In meinem Beispielanwendungsfall für ein mit Währung hantierendem Programm muss der Quellcode nicht wissen, dass es USD oder EUR gibt.

Auch sonst fällt mir grade kein Anwendungsfall ein, bei dem ich ohne Enums nicht weiter käme.

Für eine Script-Sprache ist es schon in Ordnung, wenn sie nicht mit zu viel Features gepolstert ist. Das macht den Compiliervorgang einfacher und schneller (jedenfalls in meiner Vorstellung), der muss ja schließlich zu jedem Script-Lauf gestartet werden (Cache-Mechanismen mal unbeachtet gelassen).

echo "$verabschiedung $name";

[Christian Seiler]

Hallo Christopher,

Für den geplanten Anwendungsfall PHPs ist die Typsicherheit meist kein ausschlaggebendes
KO-Kriterium. Wenn es für deine Zwecke eins ist, nur zu ...
Naja, in Bezug auf Sicherheit ist es schon nicht so schoen. ein typisches Beispiel: Man
schleift eine ID in der URL mit und moechte diese spaeter verwenden. Wer garantiert, dass
es tatsaechlich ein integer Wert ist und kein String oder Amount? Die bereits oben
erwaehnte Disziplin hilft hier natuerlich weiter (man hat ja mitterweile sein Bibliothek,
wuie zB isIntAndNotNull() oder so was). Aber jeden Typ manuell zu ueberpruefen ist
schon ein wenig nervenraubend..

Öhm, und in typsicheren Sprachen muss man die Werte sowieso immer einzeln casten, der einzige Vorteil, der typsicheren Sprachen ist, dass man gezwungen ist, sie zu casten, während man bei nicht typsicheren Sprachen das mal vergessen kann. Aber wenn Du das Überprüfen als "nervenraubend" empfindest, dann ist es egal, was für eine Sprache Du nun verwendest. Und die meisten Werte, die so im Web kursieren, sind Strings, d.h. da fällt das Argument schon in sich zusammen, denn ein String ist auch in einer streng typisierten Sprache trotzdem noch ein String. ;-)

Es gibt genug Argumente für Typsicherheit, Deines ist aber keins.

Viele Grüße,
Christian

[Christian Seiler]

Hallo dedlfix,

Operatorenueberladung

Kann man das bei einer Sprache, die nicht streng typisiert ist, sinnvoll anwenden?

Ja, kann man. Nur, weil eine Sprache nicht typ_sicher_ ist, heißt es nicht, dass sie nicht typisiert ist. Das ist ein Unterschied. Eine Variable hat in PHP *immer* einen festgelegten Datentyp, den Du per get_type() bekommst und falls die Variable vom Typ 'object' ist hat sie *immer* eine festgelegte Klasse, Die Du per get_class() bekommst.

Wie funktioniert denn Operatorüberladung z.B. in C++? Der Compiler schaut sich die Variablen an, die für den Operator gegeben sind, und sucht sich den passensten Operator heraus - bzw. spuckt einen Fehler aus, falls gar kein Operator passt. Allerdings wird das zur Kompilierzeit durchgeführt.

In meinen Augen spräche absolut nichts dagegen, sich zur Laufzeit den passendsten Operator herauszusuchen. Zumindest gibt es für Objekte in PHP5 Type Hinting, d.h. zumindest, um Objekte zu unterscheiden, könnte man das implementieren. Das ginge genauso mit Methoden und Funktionen (und zwar *nicht* über Reflection, sondern direkt) und nicht nur mit Operatoren. Für meine Datumsklasse hätte ich es extrem praktisch gefunden, wenn ich etwas wie $date += $interval_4_days; hätte implementieren können.

Insofern muss ich Christopher hier absolut zustimmen, dass das ein Manko von PHP ist. Es ist in meinen Augen allerdings kein Manko von nicht typsicheren Sprachen.

Viele Grüße,
Christian

[hkl]

Hallo !

Der Ansatz ist einfach nicht ernst zu nehmen. Wichtige Sachen wie Generics,

Das sollte aber imho ueber einen Branch eingefuehrt werden.Als Templates in C++ eingefuehrt wurden machte die Umsetzung erheblich Probleme - diese
--fno-implicit-templates option beim gcc(g++) ruehrt meines Wisses daher.

Mehrfachvererbung

Wie wuerdest Du dir das Wuenschen

• ala C++ volle Mehrfachvererbung, egal ob die die Basisklassen abstrakt sind oder nicht

oder

• ale Java vole (Implementierungs-) Vererbung nur einmal aber (abstrakte) n-Schnittstellen.

[...] Singleton-Patterns*
* oder gibt es das mitterweile?

Dazu hab ich unlaengst ein bisschen
PHP4 Code gefunden:

function & singleton()
{
    $inst_name = "_INSTANCE_" . strtoupper(__CLASS__);
    if (isset($_SESSION))
    {
        if (!isset($_SESSION[$inst_name]))
        $_SESSION[$inst_name] =& new Cart();
            return $_SESSION[$inst_name];
    }
    else
    {
        if (!isset($GLOBALS[$inst_name]))
        $GLOBALS[$inst_name] =& new Cart();
            return $GLOBALS[$inst_name];
    }
}

Na ja, das new(), das man da braucht, kann man aber halt nicht verstecken.

Und fuer
PHP5

Im Prinzip benutzen beide Stellen ein array dafuer, nur mittels des nuen Schluesselwortes "static" kann man das auch tatsaechlich im Scope der Klasse halten.
Warum das unter PHP5 noch ein array ist versteh ich eigentlich nicht; eigentlich soll ein Singleton ja grade "eins" und nicht "viele" sein...

Gruss

Holger

[dedlfix]

echo $begrüßung;

[...] Singleton-Patterns*
function & singleton()
{
    $inst_name = "_INSTANCE_" . strtoupper(__CLASS__);
    if (isset($_SESSION))
    {
        if (!isset($_SESSION[$inst_name]))
        $_SESSION[$inst_name] =& new Cart();
            return $_SESSION[$inst_name];
    }
    else
    {
        if (!isset($GLOBALS[$inst_name]))
        $GLOBALS[$inst_name] =& new Cart();
            return $GLOBALS[$inst_name];
    }
}

Das ist nicht wirklich hübsch, da man sowohl bei $_SESSION als auch bei $GLOBALS direkt auf die Instanz zugreifen kann. PHP4 kennt auch schon das Schlüsselwort static. Statische Variablen in einer Funktion sind nur innerhalb dieser verfügbar und behalten ihren Inhalt beim Verlassen der Funktion. Das wäre ein geeigneterer Ort, um die eine Instanz zu hinterlegen. Außerdem ist die Aufgabe und Arbeitsweise von $_SESSION und $GLOBALS doch eine andere. Mir wäre das suspekt, beide als quasi gleichwertig zu verwenden.

Und fuer PHP5

Das ist ein Repository. Dessen Aufgabe ist es, Instanzen an einem zentralen Punkt zu sammeln, damit diese nicht "in der Gegend rumliegen" oder ständig weitergereicht werden müssen.
Das Beispiel dort ist ein auf Singletons spezialisiertes Repository. Pro Klasse kann es nur eine Instanz aufnehmen.
Man kann ein Repository auch so schreiben, dass nicht der Klassenname sondern ein frei verwendbarer Bezeichner zum Zugriff auf die Instanzen genommen werden kann. Damit können dann auch mehrere Instanzen der gleichen Klasse darin abgelegt werden.

Im Prinzip benutzen beide Stellen ein array dafuer, nur mittels des nuen Schluesselwortes "static" kann man das auch tatsaechlich im Scope der Klasse halten.

Beide Codestellen kann man nur bedingt miteinander vergleichen. Dein PHP-4-Beispiel ist eine Methode aus einer Klasse. Das erzeugte Objekt wird nur an einer Stelle gespeichert, die zufälligerweise ein Element eines Arrays ist. Der Autor hat sicher nur keinen besseren Platz gefunden.

Warum das unter PHP5 noch ein array ist versteh ich eigentlich nicht; eigentlich soll ein Singleton ja grade "eins" und nicht "viele" sein...

Eine einfache Anwendung des Singleton-Musters findest du im PHP-Handbuch. Da ist die Speicherstelle kein Array.

echo "$verabschiedung $name";

[hkl]

Hallo !

PHP4 kennt auch schon das Schlüsselwort static.

Statische Variablen in einer Funktion sind nur innerhalb dieser verfügbar und behalten ihren Inhalt beim Verlassen der Funktion. Das wäre ein geeigneterer Ort, um die eine Instanz zu hinterlegen.

Gute Idee !

Lokale statics verwende ich nicht gerne. Aber hier wuerd's wirklich passen, da der Status ja in der Funktion selber unabhaengig von externem Status verwaltet wird.

Ausserdem ist PHP ja wohl "threadsicher" ( weil's nur einen logischen Thread in einer Sitzung gibt ) oder wie siehst Du das ?

Das ist ein Repository. Dessen Aufgabe ist es, Instanzen an einem zentralen Punkt zu sammeln, damit diese nicht "in der Gegend rumliegen" oder ständig weitergereicht werden müssen.
Das Beispiel dort ist ein auf Singletons spezialisiertes Repository. Pro Klasse kann es nur eine Instanz aufnehmen.

GoF nennen das wohl Singleton-Registratur. Trotzdem halte ich nichts von der Delegation an eine andere Klasse zur Singleton-Erzeugung. Ausser wenn das fuer den Client transparent erfolgt - siehe mein Beitrag im andren Zweig dieses Threads.
Die statische Erzeugungsfunktion des Musters ist ja gerade als zentraler Zugriffspunkt entworfen.
Bei der Typunsicherheit von PHP finde ich konzeptionell sauberer, Typen dort zu nuzten wo's mal geht.
Fehler sind dann auch leichter zu finden.

Man kann ein Repository auch so schreiben, dass nicht der Klassenname sondern ein frei verwendbarer Bezeichner zum Zugriff auf die Instanzen genommen werden kann. Damit können dann auch mehrere Instanzen der gleichen Klasse darin abgelegt werden.

Im Prinzip benutzen beide Stellen ein array dafuer, nur mittels des nuen Schluesselwortes "static" kann man das auch tatsaechlich im Scope der Klasse halten.

Beide Codestellen kann man nur bedingt miteinander vergleichen. Dein PHP-4-Beispiel ist eine Methode aus einer Klasse. Das erzeugte Objekt wird nur an einer Stelle gespeichert, die zufälligerweise ein Element eines Arrays ist. Der Autor hat sicher nur keinen besseren Platz gefunden.

Da mag sein, aber das find ich semantisch sehr fragwuerdig. Selbstdokumentierend ist das das nicht.

»»PHP5

Danke fur den Link, hab btw. fuer Perl was Praktisches in der Richtung gefunden.
Perl Pattern

Gruss

Holger

[dedlfix]

echo $begrüßung;

Ausserdem ist PHP ja wohl "threadsicher" ( weil's nur einen logischen Thread in einer Sitzung gibt ) oder wie siehst Du das ?

Ich bin nicht sehr erfahren im Umgang mit Threads, hab nur einmal damit was unter C#/.NET-Framework angestellt. Unter PHP hat es mich noch nie wirklich interessiert, da es da kein Thema zu sein scheint. Allerdings las ich, dass unter Umständen setlocale() nicht sicher vor Einflüssen aus "nebenan" laufenden Scripts sei, siehe die Warnung auf der verlinkten Seite.

Und wenn ich so über das Thema nachdenke, fällt mir ein, dass ich noch nirgends was parallellauftechnisch Negatives zu PHPs internen Abläufen las oder es selbst erfuhr, es betrifft immer nur Dinge, die außerhalb liegen, wie beispielsweise konkurrierende Dateizugriffe und Datenbankzugriffe, bei denen man mit Locks hantieren muss. Aber zählt das überhaupt zum Thema Threadsicherheit?

echo "$verabschiedung $name";

[Christian Seiler]

Hallo,

• ale Java vole (Implementierungs-) Vererbung nur einmal aber (abstrakte) n-Schnittstellen.

Das geht in PHP5 bereits auch schon, wenn auch nicht alles unterstützt wird, was in Java geht:

http://de3.php.net/manual/de/language.oop5.interfaces.php

Viele Grüße,
Christian

[babba]

Lohn es da überhaupt noch PHP zu nehmen, und nicht mspx oder aspx, oder

[hkl]

Hallo !

Lohn es da überhaupt noch PHP zu nehmen, und nicht mspx oder aspx, oder

.Net und aspx kenn ich zwar nicht sehr gut, dafuer kenne aber die ( ASP || (serverseitiges) JavaScript || COM ) - Teilmenge ein wenig.

Das ganze Konzept komponentenbasierter, sprachunabhaengiger Webarchitektur ist imo "reinem"  PHP deutlich ueberlegen - das ist aber auch keine Wunder, da man eigentlich Aepfel und Birnen vergleicht, aber dazu spaeter mehr.

Unter ASP ( und somit erst recht unter ASPX )  kann ich Komponenten die in irgendeiner beliebigen Sprache geschrieben sind der Funktionalitaet der Webseite hinzufuegen .
Zwar ist Javascript genausowenig wie PHP alles andere als typsicher - aber wenn der Hauptteil der Anwendungsloigk in den COMponenten liegt hat man hier mit IDL-Typen zu tun und innerhalb der Komponenten mit eienr Typisierung die so streng sein kann wie es die Sprache ( z.B. C++ ) halt zulaesst.

PHP ist , nach dem was ich ueber die Sprache gelesen habe, speziell fuer das Web geschrieben worden. Es wundert mich deshalb immer ein wenig, das PHP solch eine "fette" Datenbank-Schnittstelle hat. Sicherlich ist auch ein Webserver ein Applikations-"Container", aber DESHALB die Anwendungslogik dort auch gleich vollstaendig mitunterzubringen ist imo keineswegs konzeptinell angemessen.

Man kann natuerlich nach bewaehrtem Muster die Anwendungslogik weitgehend an Stored Procedures und Trigger delegieren. Gibt nur zwei Dinge dabei zu berucksichtigen

1. Die Objektklammer liegt dann trotzdem erst in der GUI-Schicht
2. Nicht jede Datenbank unterstuetzt SP's - MySQL z.B. erst ab den recht neuen 5er Versionen

Um die Flexibilitaet vo ASP-Architekturen, also insbesondere echte 3-Layer zu realisieren, wird man nicht umhinkommen, Teile der Anwendung an externe Komponenten zu delegieren. SOAP und XMLRPC kommen hier imo erheblich in Betracht.

Wenn man das macht, kann man mit PHP wahrscheinlich fast das gleiche erzielen, was man mit ASP hinbekommt.

Allerdings vermisse nach wie vor ein Application_OnStart wie bei ASp in der global.asa

Gruss

Holger

P.S.: Es gibt unter ASP die Maxime dass man Komponenten "nach Moeglickeit" im IIS laufen lassen sollte und nicht in einem externen Prozess. Nach meiner Erfahrung beruht das auf einem Denkfehler. COM-Prozesse werden von OLE immer dann gestartet wenn eine Classfactory instanziiert werden muss. Wenn das ein einfacher "Out-of-process" Server ist, hat man sicherlich den gleichen Overhead wie bei CGI.
Lokale COM Services hingegen, die also unabhaengig von einem Request laufen  , haben diesen Overhaed nicht. Und da sowohl "in-process" ( also hier "in-IIS") als auch lokal "inter-process" zwischen lokalen =>M<=TAs ( ! wichtig ) nach meiner Kenntnis mittels shared memory kommuniziert wird, seh ich den Overhead nicht.
Konnte ich auch bei Messungen nie feststellen.