PHP 6 ist tot!
-
php ist ja deswegen nicht unbenutzbar. Und die Entwicklung eingestellt wurde auch nicht.
-
zwutz schrieb:
php ist ja deswegen nicht unbenutzbar. Und die Entwicklung eingestellt wurde auch nicht.
jep. Setzte weiterhin auf PHP und wenn irgendwo nicht PHP verwendet wird. Na dann verwende ich eben die eingesetzte Sprache 
- Habe ich kein Problem damit 
-
c++ ist eine andere liga.
vermutlich werden ruby und andere serverseitige skriptsprachen noch mehr ins gespräch kommen, php6 wird nicht weiterentwickelt.. na dann, trotzdem wird php eine strecke weiter lang genutzt.
-
alternativ könnte man auch einfach shell-scripts in den CGI-Ordner packen ^^ macht sich besonders gut, wenn irgend ein lustiger admin den apache mal wieder einfach unter root gestartet hat..
Aaber ich glaub, der breakingnews hat das Ganze nicht genau genug gelesen. PHP wird weiter bestehen. Allerdings ist das aktuelle Projekt zur Entwicklung von PHP 6 nach Ansicht von Joye zum Scheitern verurteilt, weil es viel zu chaotisch läuft. Sei es drum. Ich bin mit PHP 5 auch noch zufrieden.
-
Die einzige Überraschung ist, wieso der Kernentwickler bei Microsoft ist und nicht bei Zend ist
-
zeh plus plus ist eindeutig die Zukunft von Webanwendungen
-
C++ Webentwicklung "???"...
Das heißt ja lediglich das die jetzige 6.0 nicht mehr weiterkommt, aber er deutet zugleich an, dass eventuell auf Basis von 5.3 eine NEUE 6.0 Entwickelt werden kann. (wieso überhaupt, bin immo eigentlich ganz zufrieden mit der PHP Version, kommt da was neues oder wie?).
MfG
-
derFer schrieb:
(wieso überhaupt, bin immo eigentlich ganz zufrieden mit der PHP Version, kommt da was neues oder wie?).
MfGKann ja nicht jeder so wie die Linux-Entwickler ein dreiviertel Jahrzehnt an Mikroversionsnummern herumfuchteln
Im Ernst: Es gibt viele Macken in PHP, die seit Jahren ungestopft sind. Was mich konkret an der jetzigen Version z.B. stört wäre:
- Unicode ist nach wie vor ein Krampf
- Die gesamte Funktionsbibliothek ist inkonsequent, da man ja Rückwärtskompatibilität wahren will. Einfach mal konsequent aufräumen, entrümpeln, vereinheitlichen.
- Es gibt immer noch kein Parameter Type Hinting für andere Datentypen als Objekte und Arrays. Wieso nicht?Würde ich länger darüber nachdenken fiele mir bestimmt noch mehr ein.
-
árn[y]ék schrieb:
- Es gibt immer noch kein Parameter Type Hinting für andere Datentypen als Objekte und Arrays. Wieso nicht?
Bin sowieso kein Fan davon... Mach das lieber ueber phpdoc.
Dem Rest stimme ich aber zu. Wobei unicode langsam tragbar ist (nicht gut, aber tragbar - da man meistens ohne preg_ auskommt...)Was mich am meisten stoert sind aber non recoverable errors.
Ich will ein include dass failed wenn es einen parse error oder dergleichen gibt. mit eval() kann man einiges abfangen, aber nicht alles.und ich will einen internal error handler haben!
ich hasse es dass der user ab und zu php fehlermeldungen sieht.Aber das wird auch in PHP27 noch nicht gefixt sein
-
Shade Of Mine schrieb:
und ich will einen internal error handler haben!
ich hasse es dass der user ab und zu php fehlermeldungen sieht.http://php.net/set_error_handler ?
Zugegeben, hat ein paar Einschränkungen. Aber wenn der mal nicht greifen kann, hat man eh ein größeres Problem, als dass der Benutzer ne Fehlermeldung sieht
-
zwutz schrieb:
http://php.net/set_error_handler ?
Zugegeben, hat ein paar Einschränkungen. Aber wenn der mal nicht greifen kann, hat man eh ein größeres Problem, als dass der Benutzer ne Fehlermeldung sieht
Wir hatten frueher zB ziemliche Probleme mit XML Parsing. Es konnte sein dass die Extension abgeschmiert ist weil zB memory limit oder max execution time erreicht war oder einfach weil sie fehlerhaft war. Jedenfalls fuehren solche Faelle zu leicht recoverbaren Fehlern, die aber wegen der PHP struktur nicht recoverbar sind.
Wenn man ein Framework entwickelt ist es das selbe. Wenn ein template einen Fehler verursacht, kann man easy recovern - nur PHP laesst einen nicht
Es gibt mittlerweile ja wenigstens E_RECOVERABLE_ERROR, aber leider ist das nur ein tropfen auf den heissen Stein.
E_PARSE ist zB by definition recoverable. Aber leider nicht fangbar. Einige E_ERROR sind natuerlich nicht fangbar, aber einige eben schon (zB unedefined function called).
-
Todgesagte leben länger
-
Shade Of Mine schrieb:
Ich will ein include dass failed wenn es einen parse error oder dergleichen gibt. mit eval() kann man einiges abfangen, aber nicht alles.
Das geht! Es gibt zwar keine builtin Funktion dafür, aber sowas lässt sich (leider recht umständlich) nachbilden.
Insgesamt ist die Meldung doch gar nichts Schlimmes! Na schön, PHP6 wurde eingestellt... na und? Bislang hat sich wohl kaum jemand auf die Entwicklung damit vorbereitet und das Release war ja seit je her so genau datiert wie die Rückkehr von Jesus.
Also, was hat sich unterm Strich für den Endbenutzer geändert? Richtig: Die Entwickler investierten nun mehr Zeit in die Verbesserung bereits genutzter Versionen! Ist doch toll! PHP ist tot, es lebe PHP.
C++ zu nutzen.. hmm ja.. wie wär's denn gleich mit Assembler?
