Hallo allerseits,

wir wollen unser Intranet - mehrere 1000 Zeilen Code von ca. 5 Dutzend
Programmierern in > 5 Jahren - von PHP4 anlässlich des bevorstehenden
Supportendes auf PHP6 umstellen, uns also PHP5 sparen. Jeder Programmierer
soll seinen Code selbst umsetzen =:-/ - wenn PHP6 stable erschienen ist :-)

Meine Frage ist nun, ob es schon etwas wie eine Migrationsinfo gibt. Auf
php.net bin ich nur bis zur Migration auf PHP5 fündig geworden. In der Info
zum Online-Manual steht, dass auch Doku zu PHP6 enthalten sein kann. Aber
eine Zusammenfassung habe ich noch nicht gefunden. Ich gehe aber davon aus,
dass das, was unter Migration zu PHP5 steht, immer noch gilt, insbesondere
"New Functions", "New Directives" und "New Object Model". Der "Userland
Naming Guide" scheint eher ein Fragment als eine Doku zu sein :-(

http://cvs.php.net/viewcvs.cgi/php-src/NEWS?view=markup ist zwar korrekt,
aber etwas zu knapp ;-)

Ansonsten finde ich entweder Webseiten von 2005/2006, aber nichts wirklich
aktuelles - außer Wishlists...

Kann mir hier jemand weiterhelfen?

TIA
Werner

--
Werner Flamme, Abt. WKDV
Helmholtz-Zentrum für Umweltforschung GmbH - UFZ
Permoserstr. 15 - 04318 Leipzig
Tel.: (0341) 235-3921 - Fax (0341) 235-453921
http://www.ufz.de - eMail: werner.flamme [at] ufz.de

Werner Flamme schrieb:

> Supportendes auf PHP6 umstellen, uns also PHP5 sparen. Jeder Programmierer
> soll seinen Code selbst umsetzen =:-/ - wenn PHP6 stable erschienen ist :-)

Weiss nicht, ob man dies möchte.

http://www.phpbar.de/w/PHP_6
http://www.strassenprogrammierer.de/php-6-neue-funktionen-un d-alte-lasten_tipp_359.html

So wie es ausschaut, wird vor allem internes geändert (utf-8) und der
Rest sollte eigentlich schon jetzt umgesetzt worden sein.


> Meine Frage ist nun, ob es schon etwas wie eine Migrationsinfo gibt.
> eine Zusammenfassung habe ich noch nicht gefunden. Ich gehe aber davon aus,
> dass das, was unter Migration zu PHP5 steht, immer noch gilt, insbesondere
> "New Functions", "New Directives" und "New Object Model". Der "Userland
> Naming Guide" scheint eher ein Fragment als eine Doku zu sein :-(

Sollte alles bleiben. Evtl. ändern manche API von speziellen Funktionen,
doch dies kann man dann anpassen, wenn die 6.0 definitiv erschienen ist.


> Ansonsten finde ich entweder Webseiten von 2005/2006, aber nichts wirklich
> aktuelles - außer Wishlists...

Nun, ich finde auch nicht mehr, doch habe ich vor etwa 1/2 Jahr
schmerzfrei umgestellt. Durfte noch ein paar Leichen entsorgen, doch das
war es wert.

Für etwas gibt es ja Server die man intern hat, so dass man die neue
Funktionalität sorgenfrei testen kann.

Gruss, Markus

--
Sehr zu empfehlen:

http://www.google.ch/ oder .de/ oder .com/ usw.

Markus Grob schrieb am 06.09.2007 14:18:
> Werner Flamme schrieb:
>
>> Supportendes auf PHP6 umstellen, uns also PHP5 sparen. Jeder Programmierer
>> soll seinen Code selbst umsetzen =:-/ - wenn PHP6 stable erschienen ist :-)
>
> Weiss nicht, ob man dies möchte.

Dito ;-)

> http://www.phpbar.de/w/PHP_6
> http://www.strassenprogrammierer.de/php-6-neue-funktionen-un d-alte-lasten_tipp_359.html

Ja, so ungefähr diesen Informationsgehalt habe ich auch gefunden. "Zu früh
etwas zu sagen", Links auf Protokolle vom August 2005 usw.

> So wie es ausschaut, wird vor allem internes geändert (utf-8) und der
> Rest sollte eigentlich schon jetzt umgesetzt worden sein.

Eben. Sollte. Ich hasse es, im Trüben zu angeln...

>> [Migration PHP4 -> PHP5]
>
> Sollte alles bleiben. Evtl. ändern manche API von speziellen Funktionen,
> doch dies kann man dann anpassen, wenn die 6.0 definitiv erschienen ist.

Was sind "spezielle Funktionen"? ;-) Was ist z. B. mit den
Oracle-oci-Funktionen? Wir haben hunderte von ociExecute, ociDefineByName
und dergleichen im Code. Derzeit sind es noch Aliase auf die neuen
Funktionen oci_execute, oci_define_by_name usw. Wie lange bleibt das
erhalten? Fällt es jetzt schon unter "entfernen sämtlicher veralteter
Funktion" (http://www.phpbar.de/w/PHP_6)? So etwas könnte uns töten, weil
seit dem Schreiben des Code tlw. neue Parameter eingeführt wurden und deren
Defaults sich zwischendurch mal geändert haben :-(

>> Ansonsten finde ich entweder Webseiten von 2005/2006, aber nichts wirklich
>> aktuelles - außer Wishlists...
>
> Nun, ich finde auch nicht mehr, doch habe ich vor etwa 1/2 Jahr
> schmerzfrei umgestellt. Durfte noch ein paar Leichen entsorgen, doch das
> war es wert.

Bei uns benutzen einige wenige Kollegen Klassen, die werden einiges zu tun
haben (z. B. die Konstruktoren umtaufen). Die Mehrzahl programmiert rein
prozedural, die sparen die Arbeit dann weitgehend.

> Für etwas gibt es ja Server die man intern hat, so dass man die neue
> Funktionalität sorgenfrei testen kann.

Wir werden neben dem normalen DEV-Server noch einen 2. benutzen. Wir können
uns ja nicht den Development-Server abschießen ;-) Der Kern des CMS wurde
vom Chef programmiert, und der hat meist anderes zu tun als hier und da ein
paar Anweisungen zu ändern.

>
> Gruss, Markus
>

Naja, habe erstmal den Snapshot vom 29.08. auf meinem Arbeitsplatz
installiert, mal sehen was so auf Anhieb hakt...

Danke für die Auskünfte,
saacht Werner

--
Werner Flamme, Abt. WKDV
Helmholtz-Zentrum für Umweltforschung GmbH - UFZ
Permoserstr. 15 - 04318 Leipzig
Tel.: (0341) 235-3921 - Fax (0341) 235-453921
http://www.ufz.de - eMail: werner.flamme [at] ufz.de

Werner Flamme schrieb:

> Ja, so ungefähr diesen Informationsgehalt habe ich auch gefunden. "Zu früh
> etwas zu sagen", Links auf Protokolle vom August 2005 usw.

Nun, leider gibt es meines Wissens keine exakte Roadmap sondern eher
ein: ja, so haben wir es jetzt umgesetzt. Ist halt so, wenn man nach
"Bedürfnis" programmiert.


> Eben. Sollte. Ich hasse es, im Trüben zu angeln...

Dann darfst Du noch warten bis die 6.0 draussen ist. Ich kann mir
vorstellen, dass nach Bedarf auch noch bei einer RC -> stable ein API
wechselt, falls man das Bedürfnis hat.


> Was sind "spezielle Funktionen"? ;-) Was ist z. B. mit den
> Oracle-oci-Funktionen? Wir haben hunderte von ociExecute, ociDefineByName

Genau solche meine ich. Da würde ich nicht im vornherein etwas umsetzen.


> erhalten? Fällt es jetzt schon unter "entfernen sämtlicher veralteter
> Funktion" (http://www.phpbar.de/w/PHP_6)? So etwas könnte uns töten, weil
> seit dem Schreiben des Code tlw. neue Parameter eingeführt wurden und deren
> Defaults sich zwischendurch mal geändert haben :-(

Nun, es wird sicher Konverterklassen geben, doch das sieht man sicher
mit erscheinen von 6.0 ;-)


> Bei uns benutzen einige wenige Kollegen Klassen, die werden einiges zu tun
> haben (z. B. die Konstruktoren umtaufen). Die Mehrzahl programmiert rein
> prozedural, die sparen die Arbeit dann weitgehend.

Nun, etwas vom 6.0 soll ja sein, dass man anschliessend keine Sorgen
mehr haben muss mit gleichen Klassennamen, da dann mit Bibliotheken
gearbeitet wird. Oder habe ich hier etwas gemischt?


> Wir werden neben dem normalen DEV-Server noch einen 2. benutzen. Wir können
> uns ja nicht den Development-Server abschießen ;-)

:-) Nun, einen solchen Server kann man ja schnell virtuell aufsetzen.
Ist ja nur eine php-Testumgebung.


> Der Kern des CMS wurde
> vom Chef programmiert, und der hat meist anderes zu tun als hier und da ein
> paar Anweisungen zu ändern.

Wirklich? ;-)


> Naja, habe erstmal den Snapshot vom 29.08. auf meinem Arbeitsplatz
> installiert, mal sehen was so auf Anhieb hakt...

Nun, ist empfehlenswert.

Gruss, Markus, zur Zeit versuchend, etwas mehr OO in seinen prozeduralen
Programmierstil hineinzubringen.

--
Sehr zu empfehlen:

http://www.google.ch/ oder .de/ oder .com/ usw.

Werner Flamme schrieb:
> Eben. Sollte. Ich hasse es, im Trüben zu angeln...

Darum würde ich mir bisher noch keine Gedanken machen was PHP 6 angeht.
Ist ja nicht mal sicher, was alles geändert wird (oder?). Höchstens,
dass man bei Neuentwicklungen sich mal informiert, was sich
voraussichtlich ändert und dann bei den neuen Sachen schaut, dass da
nichts über den Haufen geworfen wird.

> Bei uns benutzen einige wenige Kollegen Klassen, die werden einiges zu tun
> haben (z. B. die Konstruktoren umtaufen). Die Mehrzahl programmiert rein
> prozedural, die sparen die Arbeit dann weitgehend.

Soweit man bisher über die möglichen Änderungen von PHP 6 sagen kann,
dürfte die Umstellung bei weitem schneller gehen, als das Konzept eines
Projektes vom prozeduralen Aufbau in ein Objektorientiertes zu ändern.

Wenn Ihr bisher keinerlei Probleme habt prozedural zu arbeiten, würde
ich daran auch im nachhinein nichts mehr ändern (bei bestehenden
Projekten). Mir ist nicht bekannt, dass PHP 6 OOP vorschreibt.

Und wenn Ihr unbedingt auf OOP umstellen wollt, dann würde ich
vielleicht jetzt schon damit anfangen und nicht bis PHP 6 warten. Ich
wüsste nicht, was sich am OOP noch groß ändern könnte.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:
>
> Und wenn Ihr unbedingt auf OOP umstellen wollt, dann würde ich
> vielleicht jetzt schon damit anfangen und nicht bis PHP 6 warten. Ich
> wüsste nicht, was sich am OOP noch groß ändern könnte.
>

*Jetzt* haben wir PHP4. Und da stellt sicher niemand auf OO um ;-) - ist
ja kein Zwang, weder durch Chef ;-) noch durch PHP6. Ich schrub nur über
den Unterschied oo/prozedurales Programmieren, weil der
Umstellungsaufwand für die OOen größer sein wird. Die Oracle-Calls sind
bei beiden gleichermaßen vorhanden.

Gruß
Werner

--
Werner Flamme, Abt. WKDV
Helmholtz-Zentrum für Umweltforschung GmbH - UFZ
Permoserstr. 15 - 04318 Leipzig
Tel.: (0341) 235-3921 - Fax (0341) 235-453921
http://www.ufz.de - eMail: werner.flamme [at] ufz.de

> Bei uns benutzen einige wenige Kollegen Klassen, die werden einiges zu tun
> haben (z. B. die Konstruktoren umtaufen). Die Mehrzahl programmiert rein
> prozedural, die sparen die Arbeit dann weitgehend.

Das sehe ich als geringes Problem, da kann man sich im Zweifel mit
Eclipse PDT durchklicken, bis man alle erwischt hat.
Hmmm...im Grunde könnte es reichen, wenn man mit get_declared_classes
alles durchgeht, mit get_class_methods schaut, dass __construct
existiert und der PHP4-Konstruktor nicht, ansonsten meckern lässt.

--
Mein Zeugs:
http://www.hadanite-marasek.de/classes.php
http://www.objektivsuche.de/

Werner Flamme wrote:

> wir wollen unser Intranet - mehrere 1000 Zeilen Code von ca. 5 Dutzend
> Programmierern in > 5 Jahren - von PHP4 anlässlich des bevorstehenden
> Supportendes auf PHP6 umstellen

Offensichtlich verschiebt sich PHP6 noch nen bischen. Die Entwickler
sind da noch nicht ganz so weit wie "erwartet".

Also jetzt schon für PHP6 entwickelt geht nur teilweise und auch nur
wenn man aufmerksam in den verschiedenen Mailinglisten von php.net mitliest.

Ich lese dort seit knapp 2 Jahren mit um wenigstens halbwegs auf dem
Laufenden zu bleiben.

> soll seinen Code selbst umsetzen =:-/ - wenn PHP6 stable erschienen ist :-)

Eher machts keinen Sinn. Gerad die neuen unicode-Features sind ja noch
nicht ganz ausgegohren.

> Meine Frage ist nun, ob es schon etwas wie eine Migrationsinfo gibt.

Nicht das ich wüßte. Sowas wird im allgemeinen erst dann angefangen wenn
eine Version (Beta) vorliegt, die alles wichtige mitbringt. Das geht
natürlich erst dann wenn sich wirklich alle Entwickler in den
entscheiden Punkten einig sind.

> dass das, was unter Migration zu PHP5 steht, immer noch gilt, insbesondere
> "New Functions", "New Directives" und "New Object Model".

Naja In vielen neuen Version sind auch Dinge weggefallen. Das wird bei
PHP6 auch nicht anders.

MfG, Ulf

--
_,
_(_p> Ulf [Kado] Kadner
\<_)
^^

Werner Flamme schrieb:
> Hallo allerseits,
>
> wir wollen unser Intranet - mehrere 1000 Zeilen Code von ca. 5 Dutzend
> Programmierern in > 5 Jahren - von PHP4 anlässlich des bevorstehenden=

> Supportendes auf PHP6 umstellen, uns also PHP5 sparen. Jeder Programmie=
rer
> soll seinen Code selbst umsetzen =3D:-/ - wenn PHP6 stable erschienen i=
st :-)

Hm, 5 Dutzend sind 60, und >5 Jahre mindestens 60 Monate. Das sind also
3600 Mannmonate. Da hoffe ich aber, dass "mehrere" ein großer Wert ist.=

Sonst wäre es ein ziemlich faules Pack ;-)

Nun zur Frage: PHP5 auslassen ist kompletter Unfug. Das wäre so, als
würde jemand bei einem Windows 9x Programm ABSICHTLICH alle NT-basierte=
n
Versionen vor Vista auslassen, weil... Ja keine Ahnung warum. Blöd halt=
=2E

PHP 5.0 auszulassen war bedingt legitim, weil es eine Nullversion war,
die dazu auch noch langsamer als PHP4 war. Außerdem muss man ja erstmal=

abwarten, ob nicht der "Winamp3 Effekt" auftritt und wirklich gar keiner
PHP5 mag. Spätestens mit PHP 5.1 war PHP5 jedoch produktionsreif. Der
neue Zweig hat seine Funktionsfähigkeit bewiesen, es gibt massig neue
Features (PDO), die Performance ist besser als PHP4 und noch dazu ist
die Umstellung mit weniger Arbeit verbunden als die von PHP 4.3 zu 4.4.

Davon ab: PHP 5.3 wird wohl die größten sprachlichen Verbesserungen
bringen, die für PHP6 geplant waren, weil der 6er Ast im Zeitplan hinkt=
=2E
Ist halt nicht so einfach, ALLE Funktionen für Unicdoe neu zu schreiben=
=2E
Gerade dieser Kraftakt wird potentiell auch bei der Einführung von PHP6=

für deutlich mehr =C4rger führen als es im gesamten Lebenszeitraum vo=
n
PHP5 davor der Fall war.

Also: Husch husch auf PHP5 umstellen!

> Meine Frage ist nun, ob es schon etwas wie eine Migrationsinfo gibt. Au=
f
> php.net bin ich nur bis zur Migration auf PHP5 fündig geworden. In de=
r Info
> zum Online-Manual steht, dass auch Doku zu PHP6 enthalten sein kann. Ab=
er
> eine Zusammenfassung habe ich noch nicht gefunden. Ich gehe aber davon =
aus,
> dass das, was unter Migration zu PHP5 steht, immer noch gilt, insbesond=
ere
> "New Functions", "New Directives" und "New Object Model". Der "Userland=

> Naming Guide" scheint eher ein Fragment als eine Doku zu sein :-(

Erstmal: Richtig, die PHP5-Migration gilt weiterhin und bleibt einem
nicht erspart, wenn man direkt von PHP4 nach PHP6 wechselt. Je länger
man wartet, desto mehr Dokumente darf man abarbeiten. Der Userland
Naming Guide ist nur eine Empfehlung und keine Bibel.

OLLi

--
Logic: The art of being wrong with confidence...

Werner Flamme schrieb:
>
> *Jetzt* haben wir PHP4. Und da stellt sicher niemand auf OO um ;-)

Es hängt letztendlich nur von der Wartbarkeit eures Codes ab, ob und
wann ihr auf OO umstellt. Wenn ihr unorganisierte bunte
Funktionsansammlungen ohne festes Namensschema in mehreren hundert
Dateien habt, dann wird schon bald die Produktivität bei der Erweiterun=
g
des Codes stark leiden. In der Regel sorgt OO von ganz alleine für mehr=

Ordnung. Darüber sollte man gründlich nachdenken, sonst lauert da ein=
e
Zeitbombe...

OLLi

--
X:"I was working hard for that money."
S:"And I didn't?"
X:"You stole it."
S:"And you're making it very hard work"
[Buffy 514]