nicht angemeldet
PHP 7.0 - Schritt in die richtige Richtung, aber Chance verfehlt
http://php.net/archive/2015.php#id2015-12-03-1
Das Update hat keine großen Überraschungen an Board: Man trennt sich von toten Codezweigen, macht die Sprache in vielen Punkten konsistenter und schraubt an der Performance. Auf der anderen Seite bleibt PHP langweilig und unattraktiv für Entwickler. Mich wundert ein wenig, warum man nicht versucht hat, mehr von Hack zu profitieren.
-
Moin!
http://php.net/archive/2015.php#id2015-12-03-1
Das Update hat keine großen Überraschungen an Board: Man trennt sich von toten Codezweigen, macht die Sprache in vielen Punkten konsistenter und schraubt an der Performance. Auf der anderen Seite bleibt PHP langweilig und unattraktiv für Entwickler. Mich wundert ein wenig, warum man nicht versucht hat, mehr von Hack zu profitieren.
Welche Vorteile wären das? Werde mal konkret - nicht immer dieses Wischiwaschi-Gebashe von PHP.
Grüße Sven
-
Welche Vorteile wären das? Werde mal konkret - nicht immer dieses Wischiwaschi-Gebashe von PHP.
Gerne, hier ist meine lose zusammengestellte und unvollständige Wunschliste von Entwicklungen, die ich für diskussionswürdig halte. Mit der Befürwortung eines Features möchte ich nicht ausdrücken, dass es um jeden Preis in PHP landen sollte, es ist selbstverständlich oft Abwägungssache.
Am meisten begehre ich eine verbesserte Unterstützung für funktionale Programmierung. PHP Closures sind durch die notwendige use-Klausel unfassbar verbose, da erhoffe ich mir eine deutliche knappere Syntax mit impliziter Bindung freier Variablen. Außerdem wünsche ich mir ein asynchrones Event-Handling für langlebige PHP-Prozesse und mehr Designfreiheiten wenn es zur Modelleriung komplexer Kontrollflüsse kommt, sprich APIs oder syntaktischen Zucker für Funktions-Komposition, Promises, Streams oder Continuation Passing Style. Performance-Optimierungen für endrekursive Funktionen sind ein Muss, vor allem sollten endrekursive Funktionen keine Stackoverflows auslösen. Pattern-Matching bei Funktionsdefinitionen wäre der Hit.
Das PHP-Modulsystem ist mir der nächste große Dorn im Auge. Es kann kaum sein, dass eine highlevel Skriptsprache ein lowlevel Modulsystem wie C benutzt, das auf Datei-Einbettung basiert. Ein dringend notwendiges Feature ist die Möglichkeit alle globalen Definitionen zu verstecken und stattdessen mit qualifizierten Imports/Exports zu arbeiten.
Die objektorientierten Features haben verglichen mit den funktionalen Features in der Vergangheit schon sehr viel Aufmerksamkeit erfahren. Hier wünsche ich mir, dass weiterhin prozedurale APIs durch objektorientierte APIs abgelöst werden, so wie es mit mysql und PDO geschehen ist. Konstruktur-Parameter-Promotion wie in Hack könnte viel Boilerplate-Code sparen. Ebenfalls von Hack inspiriert fände ich Trait- und Interface-Requirements wichtig, um verstärkt Objektkomposition über Vererbung zu featuren.
PHPs Basisoperationen auf primitiven Datentypen sind auch nicht das, was ich mir von einer highlevel Sprache erhoffe. String-Manipulation sollte von Haus aus UTF8-kompatibel sein oder zumindest per Opt-In aktiviert werden können. Ganz ähnlich würde ich mir exakte Operationen zum Rechnen mit rationalen Zahlen wünschen, das selbe für reelle und komplexe Zahlen wäre ein Sahnehäupchen.
Und ganz ganz dringend sollte PHP seine Debugging-Kapazitäten erhöhen. Die Debugging-SAPI von PHP 5.6 ist nie gelandet. Die beiden drittanbieter Debugger XDebug und Zend-Debugger sind brauchbar, bilden aber auch nicht die Sperrspitze der Entwickler-Tools. Unterstüztung für Timetravel-Debugging wäre ein wahres Killerfeature. Ebenso würde ich eine Möglichkeit feiern, bei Fehlern den Systemzustand zu snapshotten und später auf einer Debugging-Umgebung wieder herzustellen.
Zuletzt wäre da noch PHPs unglaublicher Bulk an Konfigurations-Möglichkeiten, den müsste man dringend aufräumen. Hier sollte man in Kooperation mit Deployment-Platformen und Paket-Managern eine langfristige Lösungsstrategie entwickeln. Mehr Kooperation würde Zend sowieso gut stehen, ein Standard-Kommitee würde mit Sicherheit das Sprachdesign, die Implementierung und die Community auf lange Sicht stärken.
-
Das PHP-Modulsystem ist mir der nächste große Dorn im Auge. Es kann kaum sein, dass eine highlevel Skriptsprache ein lowlevel Modulsystem wie C benutzt, das auf Datei-Einbettung basiert. Ein dringend notwendiges Feature ist die Möglichkeit alle globalen Definitionen zu verstecken und stattdessen mit qualifizierten Imports/Exports zu arbeiten.
Für mich auch ein Rätsel. Da hahmse schon bei Perl ganz ungeniert gekupfert, aber das nun gerade nicht.
Zuletzt wäre da noch PHPs unglaublicher Bulk an Konfigurations-Möglichkeiten, den müsste man dringend aufräumen.
Ja, das auch.
-
Moin!
Welche Vorteile wären das? Werde mal konkret - nicht immer dieses Wischiwaschi-Gebashe von PHP.
Gerne, hier ist meine lose zusammengestellte und unvollständige Wunschliste von Entwicklungen, die ich für diskussionswürdig halte. Mit der Befürwortung eines Features möchte ich nicht ausdrücken, dass es um jeden Preis in PHP landen sollte, es ist selbstverständlich oft Abwägungssache.
Für alle Verbesserungswünsche gilt: RFC schreiben, Unterstützer gewinnen, Voting überstehen.
Am meisten begehre ich eine verbesserte Unterstützung für funktionale Programmierung. PHP Closures sind durch die notwendige use-Klausel unfassbar verbose, da erhoffe ich mir eine deutliche knappere Syntax mit impliziter Bindung freier Variablen.
Syntax-Änderungen sind nicht mal einfach eingebaut. Du musst kompatibel zu existierendem Code bleiben. Wenn dein Vorschlag bedeuten würde, dass existierender Code plötzlich mehr Variablen einbindet, und nicht mehr nur die explizit benannten, wird niemand so ein Feature einbauen wollen.
Außerdem wünsche ich mir ein asynchrones Event-Handling für langlebige PHP-Prozesse
Kann man sich machen, wenn man will. Braucht die Mehrheit von Wordpress-Blogs nicht.
und mehr Designfreiheiten wenn es zur Modelleriung komplexer Kontrollflüsse kommt, sprich APIs oder syntaktischen Zucker für Funktions-Komposition, Promises, Streams oder Continuation Passing Style.
PHP ist kein Javascript. Du kannst gern deinen JS-Code in die PHP-V8-Extension packen und ausführen.
Performance-Optimierungen für endrekursive Funktionen sind ein Muss, vor allem sollten endrekursive Funktionen keine Stackoverflows auslösen. Pattern-Matching bei Funktionsdefinitionen wäre der Hit.
Ich finde 100% Performanceoptimierung für realen Code schon ganz nett.
Das PHP-Modulsystem ist mir der nächste große Dorn im Auge. Es kann kaum sein, dass eine highlevel Skriptsprache ein lowlevel Modulsystem wie C benutzt, das auf Datei-Einbettung basiert. Ein dringend notwendiges Feature ist die Möglichkeit alle globalen Definitionen zu verstecken und stattdessen mit qualifizierten Imports/Exports zu arbeiten.
Das Modulsystem von PHP ist der Grund, warum heutzutage alle damit Arbeiten, und warum man fast alle beliebige Infrastruktur an PHP anbinden kann. Was interessiert dich als PHP-Entwickler die Implementierung der Extensions?
Du kannst bereits jetzt im Namespace arbeiten und die gesamte Welt um dich herum ignorieren.
Die objektorientierten Features haben verglichen mit den funktionalen Features in der Vergangheit schon sehr viel Aufmerksamkeit erfahren. Hier wünsche ich mir, dass weiterhin prozedurale APIs durch objektorientierte APIs abgelöst werden, so wie es mit mysql und PDO geschehen ist. Konstruktur-Parameter-Promotion wie in Hack könnte viel Boilerplate-Code sparen. Ebenfalls von Hack inspiriert fände ich Trait- und Interface-Requirements wichtig, um verstärkt Objektkomposition über Vererbung zu featuren.
Es hat 10 Jahre gedauert, die MySQL-Extension rauszuwerfen. Deswegen ist es sehr unwahrscheinlich, dass existierende APIs mal eben mir-nichts-dir-nichts durch eine Alternative ersetzt werden.
PHPs Basisoperationen auf primitiven Datentypen sind auch nicht das, was ich mir von einer highlevel Sprache erhoffe. String-Manipulation sollte von Haus aus UTF8-kompatibel sein oder zumindest per Opt-In aktiviert werden können. Ganz ähnlich würde ich mir exakte Operationen zum Rechnen mit rationalen Zahlen wünschen, das selbe für reelle und komplexe Zahlen wäre ein Sahnehäupchen.
Du weißt, warum PHP 6 gescheitert ist? Man baut nicht mal eben UTF-8-Unterstützung ein. In meiner täglichen Arbeit vermisse ich da jedenfalls nichts. Es gibt UTF-8-fähige Stringfunktionen, wenn man denn mal eine braucht.
Und ganz ganz dringend sollte PHP seine Debugging-Kapazitäten erhöhen. Die Debugging-SAPI von PHP 5.6 ist nie gelandet. Die beiden drittanbieter Debugger XDebug und Zend-Debugger sind brauchbar, bilden aber auch nicht die Sperrspitze der Entwickler-Tools. Unterstüztung für Timetravel-Debugging wäre ein wahres Killerfeature. Ebenso würde ich eine Möglichkeit feiern, bei Fehlern den Systemzustand zu snapshotten und später auf einer Debugging-Umgebung wieder herzustellen.
Kauf die die Zend-Server-Lizenz, dann kriegst du da was. Anscheinend braucht das aber kaum jemand.
Zuletzt wäre da noch PHPs unglaublicher Bulk an Konfigurations-Möglichkeiten, den müsste man dringend aufräumen. Hier sollte man in Kooperation mit Deployment-Platformen und Paket-Managern eine langfristige Lösungsstrategie entwickeln. Mehr Kooperation würde Zend sowieso gut stehen, ein Standard-Kommitee würde mit Sicherheit das Sprachdesign, die Implementierung und die Community auf lange Sicht stärken.
Es hat kaum weniger lange gedauert, das Setting für Magic Quotes rauszuwerfen, wie die MySQL-Extension.
Grüße Sven
-
Für alle Verbesserungswünsche gilt: RFC schreiben, Unterstützer gewinnen, Voting überstehen.
So viel Engagement will ich für PHP nicht aufbringen, dafür ist mir die Sprache persönlich zu rückständig, die Update-Politik zu konservativ. Es bereitet mir einfach keine Freude. Wie auch immer, dass der Entwicklungsprozess inzwischen so offen ist, begrüße ich sehr.
Am meisten begehre ich eine verbesserte Unterstützung für funktionale Programmierung. PHP Closures sind durch die notwendige use-Klausel unfassbar verbose, da erhoffe ich mir eine deutliche knappere Syntax mit impliziter Bindung freier Variablen.
Syntax-Änderungen sind nicht mal einfach eingebaut. Du musst kompatibel zu existierendem Code bleiben.
Ich habe nicht behauptet, dass man das mal eben so machen könnte. Jedes neue Feature ist natürlich mit Arbeit verbunden, ganz besonders, wenn die Sprache so weite Verbreitung genießt. Und dennoch halte ich PHPs Closures für zu wortreich, um damit expressiven Code zu schreiben. Mir ist auch keine andere Sprache bekannt, die sowas wie eine use-Klausel benutzt. Soweit ich mich erinnere hat man damit eine Performance-Optimierung in der Garbage-Collection fokusiert, die sonst nicht möglich gewesen wäre. Das ist ja auch ein gutes Argument, allerdings zu Lasten des Sprachdesigns und damit auf Kosten derjenigen, die damit entwickeln müssen.
Wenn dein Vorschlag bedeuten würde, dass existierender Code plötzlich mehr Variablen einbindet, und nicht mehr nur die explizit benannten, wird niemand so ein Feature einbauen wollen.
Bei einer alternativen Syntax für anonyme Funktionen, würde die Semantik der bisherigen Schreibweise ja unangetastet bleiben. Hacklang benutzt beispielsweise eine Fatarrow-Syntax: $bar ===> $baz
Außerdem wünsche ich mir ein asynchrones Event-Handling für langlebige PHP-Prozesse
Kann man sich machen, wenn man will. Braucht die Mehrheit von Wordpress-Blogs nicht.
Ich finde schon, dass blockierende IO-Operationen ein Performance-Flaschenhals in jeder Anwendung sind und bin mir sicher, dass auch Wordpress von einem asynchronen IO-Modell profitieren würde.
und mehr Designfreiheiten wenn es zur Modelleriung komplexer Kontrollflüsse kommt, sprich APIs oder syntaktischen Zucker für Funktions-Komposition, Promises, Streams oder Continuation Passing Style.
PHP ist kein Javascript. Du kannst gern deinen JS-Code in die PHP-V8-Extension packen und ausführen.
Wenn ich die Wahl habe, schreibe ich direkt Node.js-Anwendungen, eben weil ich so unzufrieden mit PHP bin. Hätte PHP die selben ausdrucksstarken Modellierungsmöglichkeiten wie JavaScript oder sogar PureScript, würde ich diesen Punkt gar nicht kritisieren.
Performance-Optimierungen für endrekursive Funktionen sind ein Muss, vor allem sollten endrekursive Funktionen keine Stackoverflows auslösen. Pattern-Matching bei Funktionsdefinitionen wäre der Hit.
Ich finde 100% Performanceoptimierung für realen Code schon ganz nett.
Da beißt sich die Katze doch in den Schwanz: Endrekursive Funtkionen sind nicht real, weil sie in PHP nicht performant und zuverlässig sind. Auf der anderen Seite stimme ich dir voll und ganz zu, dass die unternommen Perfromanceoptimierungen Würdigung verdienen.
Das PHP-Modulsystem ist mir der nächste große Dorn im Auge. Es kann kaum sein, dass eine highlevel Skriptsprache ein lowlevel Modulsystem wie C benutzt, das auf Datei-Einbettung basiert. Ein dringend notwendiges Feature ist die Möglichkeit alle globalen Definitionen zu verstecken und stattdessen mit qualifizierten Imports/Exports zu arbeiten.
Das Modulsystem von PHP ist der Grund, warum heutzutage alle damit Arbeiten, und warum man fast alle beliebige Infrastruktur an PHP anbinden kann.
Was interessiert dich als PHP-Entwickler die Implementierung der Extensions?
Kannst du das näher erläutern? Meiner Meinung nach ist nämlich genau das Gegenteil der Fall. PHPs require/include forciert doch gerade, dass Module in PHP geschrieben werden müssen. Haskells Modulsystem in Kombination mit der foreign Language API oder EcmaScript2015 Module sind in diesem Punkt doch wesentlich liberaler. Sie gestatten es Sofware-APIs anderer Systeme entweder nahtlos oder nur mit schmalen Wrappern einzubetten. PHP-Erweiterungen in C oder C++ sind damit verglichen äußerst selten außerhalb des privilegierten PHP-Kerns anzutreffen.
Du kannst bereits jetzt im Namespace arbeiten und die gesamte Welt um dich herum ignorieren.
Namespaces sind dann der Workaround, den man heute gehen muss.
Die objektorientierten Features haben verglichen mit den funktionalen Features in der Vergangheit schon sehr viel Aufmerksamkeit erfahren. Hier wünsche ich mir, dass weiterhin prozedurale APIs durch objektorientierte APIs abgelöst werden, so wie es mit mysql und PDO geschehen ist. Konstruktur-Parameter-Promotion wie in Hack könnte viel Boilerplate-Code sparen. Ebenfalls von Hack inspiriert fände ich Trait- und Interface-Requirements wichtig, um verstärkt Objektkomposition über Vererbung zu featuren.
Es hat 10 Jahre gedauert, die MySQL-Extension rauszuwerfen. Deswegen ist es sehr unwahrscheinlich, dass existierende APIs mal eben mir-nichts-dir-nichts durch eine Alternative ersetzt werden.
Du unterstellst mir schon wieder, ich wünschte mir diese Features so "mir-nichts-dir-nichts" herbei. Ich habe nie etwas in diese Richtung behauptet, im Gegenteil ich bin mir des enormen Arbeitsaufwandes durchaus bewusst und würdige die geleistete Arbeit in höchstem Maße.
PHPs Basisoperationen auf primitiven Datentypen sind auch nicht das, was ich mir von einer highlevel Sprache erhoffe. String-Manipulation sollte von Haus aus UTF8-kompatibel sein oder zumindest per Opt-In aktiviert werden können. Ganz ähnlich würde ich mir exakte Operationen zum Rechnen mit rationalen Zahlen wünschen, das selbe für reelle und komplexe Zahlen wäre ein Sahnehäupchen.
Du weißt, warum PHP 6 gescheitert ist? Man baut nicht mal eben UTF-8-Unterstützung ein. In meiner täglichen Arbeit vermisse ich da jedenfalls nichts. Es gibt UTF-8-fähige Stringfunktionen, wenn man denn mal eine braucht.
Ja, PHP 6 ist auch an dem überambitionierten Ziel gescheitert UTF8-Support in die Sprache einzubetten. Das war ein katasrophaler Folgeschaden, den dieser frühe Designfehler nach sich gezogen hat. Heute ist PHP daher in diesem Punkt genauso weit wie vor PHP 6. Das ist schade und das kritisiere ich an der heutigen Version von PHP. Die Argumente haben sich seither ja nicht geändert.
-
Moin!
Für alle Verbesserungswünsche gilt: RFC schreiben, Unterstützer gewinnen, Voting überstehen.
So viel Engagement will ich für PHP nicht aufbringen, dafür ist mir die Sprache persönlich zu rückständig, die Update-Politik zu konservativ. Es bereitet mir einfach keine Freude. Wie auch immer, dass der Entwicklungsprozess inzwischen so offen ist, begrüße ich sehr.
Und damit ist die Diskussion eigentlich schon zu Ende:
Das, was von der PHP-Community vorgeschlagen wurde für PHP 7, das wurde entweder nach Diskussion umgesetzt oder abgelehnt. Alles, was du hier anführst, interessiert in der PHP-Community offenbar zu wenig, als dass sich jemand drum kümmern würde.
Insofern kann ich die Kritik "Chance verpasst" nicht nachvollziehen, denn das, was umgesetzt wurde, stand eben exakt so auf dem Fahrplan. Nodejs-artiges Programmieren stand nicht drauf.
Syntax-Änderungen sind nicht mal einfach eingebaut. Du musst kompatibel zu existierendem Code bleiben.
Ich habe nicht behauptet, dass man das mal eben so machen könnte. Jedes neue Feature ist natürlich mit Arbeit verbunden, ganz besonders, wenn die Sprache so weite Verbreitung genießt. Und dennoch halte ich PHPs Closures für zu wortreich, um damit expressiven Code zu schreiben. Mir ist auch keine andere Sprache bekannt, die sowas wie eine use-Klausel benutzt. Soweit ich mich erinnere hat man damit eine Performance-Optimierung in der Garbage-Collection fokusiert, die sonst nicht möglich gewesen wäre. Das ist ja auch ein gutes Argument, allerdings zu Lasten des Sprachdesigns und damit auf Kosten derjenigen, die damit entwickeln müssen.
Warum PHP für Closures "use" benutzt, müsstest du die Implementierer zu PHP 5.3-Zeiten fragen (damals gab es noch keinen so strukturierten Featureprozess). Einer von denen war früher hier im Forum sehr aktiv: Christian Seiler. Der andere gehört zu den PHP-Core-Entwicklern: Dmitry.
Es war seinerzeit eher eine Machbarkeitsstudie, "weil man's kann". Damals, Ende 2008, war von NodeJS nichts zu hören und zu sehen, und bei Javascript-Engines war gerade das große Performance-Rennen im Gange - Javascript war, verglichen zu heute, also noch grottig lahm.
Dafür, dass PHP also eigentlich absolut nichts mit Javascript-Paradigmen zu tun hatte, und dass Christian und Dmitry sich in den grundsätzlichen Vorgaben, die PHP seinerzeit (und auch bis heute) hatte, bewegen mussten, sind die Closures und Lambdafunktionen recht gelungen.
Außerdem wünsche ich mir ein asynchrones Event-Handling für langlebige PHP-Prozesse
Kann man sich machen, wenn man will. Braucht die Mehrheit von Wordpress-Blogs nicht.
Ich finde schon, dass blockierende IO-Operationen ein Performance-Flaschenhals in jeder Anwendung sind und bin mir sicher, dass auch Wordpress von einem asynchronen IO-Modell profitieren würde.
Damit werden dann aber die Programmzusammenhänge komplexer. Schließlich brauchst du ja irgendwas sinnvolles zu tun, während du auf I/O wartest.
In diesem Sinne ist PHP übrigens problemlos parallelisiert: Während der eine Request auf I/O wartet, ist die CPU ja für den anderen Prozess frei und kann schon die Seite rendern. Das bringt der einzelnen Anfrage nichts, aber dem Gesamtbild.
Performance-Optimierungen für endrekursive Funktionen sind ein Muss, vor allem sollten endrekursive Funktionen keine Stackoverflows auslösen. Pattern-Matching bei Funktionsdefinitionen wäre der Hit.
Ich finde 100% Performanceoptimierung für realen Code schon ganz nett.
Da beißt sich die Katze doch in den Schwanz: Endrekursive Funtkionen sind nicht real, weil sie in PHP nicht performant und zuverlässig sind. Auf der anderen Seite stimme ich dir voll und ganz zu, dass die unternommen Perfromanceoptimierungen Würdigung verdienen.
Ich würde diesen Vorschlag allerdings als Spezialfallsonderoptimierung ansehen. Wieviele rekursive Funktionen hat man denn gewöhnlich in seinem Code? Und wie intensiv werden die aufgerufen? Und wie gut kann man das debuggen?
Wenn die Applikationen, die derzeit für Benchmarking von PHP 7 vs. HHVM genutzt werden, viel Gebraucht von Rekursion machen würden, wäre das bestimmt aufgefallen und schon umgesetzt.
Das Modulsystem von PHP ist der Grund, warum heutzutage alle damit Arbeiten, und warum man fast alle beliebige Infrastruktur an PHP anbinden kann.
Was interessiert dich als PHP-Entwickler die Implementierung der Extensions?
Kannst du das näher erläutern? Meiner Meinung nach ist nämlich genau das Gegenteil der Fall. PHPs require/include forciert doch gerade, dass Module in PHP geschrieben werden müssen. Haskells Modulsystem in Kombination mit der foreign Language API oder EcmaScript2015 Module sind in diesem Punkt doch wesentlich liberaler. Sie gestatten es Sofware-APIs anderer Systeme entweder nahtlos oder nur mit schmalen Wrappern einzubetten. PHP-Erweiterungen in C oder C++ sind damit verglichen äußerst selten außerhalb des privilegierten PHP-Kerns anzutreffen.
Du kritisierst "Es kann kaum sein, dass eine highlevel Skriptsprache ein lowlevel Modulsystem wie C benutzt, das auf Datei-Einbettung basiert." - anscheinend ist dir also die Anbindung von Modulen an PHP suspekt. Aber warum interessieren dich als PHP-Entwickler die internen Mechanismen, mit denen PHP dir ein Modul und damit eine Funktionserweiterung zur Verfügung stellt? Ärgerlich wird's ja nur, wenn Module nicht host-übergreifend verfügbar sind, das ist dann allerdings "nur" ein Environmentproblem und lösbar. Das dynamische Dazuladen von Modulen mit
dl()ist ja eher als nicht-existent anzusehen, insbesondere wegen der Security-Implikationen und der grundsätzlichen Inkompatibilität zu den Threadsafe-Builds.Apropos threadsafe: PHP kann Threads. Ist relativ simpel anzuwenden, halt so, wie andernorts vermutlich auch. Nutzt nur keiner - weil es komplizierter ist, sich Code auszudenken, der parallel abläuft und am Ende gemeinsame Ergebnisse zusammenzuführen, als einfach alles in einer geordneten Reihenfolge nacheinander zu tun. Wenn das schnell genug ist: Warum sollte man sich mit Race-Conditions o.ä. rumschlagen müssen?
Du kannst bereits jetzt im Namespace arbeiten und die gesamte Welt um dich herum ignorieren.
Namespaces sind dann der Workaround, den man heute gehen muss.
In Javascript ignoriert man doch auch alles außer "the good bits".
Du unterstellst mir schon wieder, ich wünschte mir diese Features so "mir-nichts-dir-nichts" herbei. Ich habe nie etwas in diese Richtung behauptet, im Gegenteil ich bin mir des enormen Arbeitsaufwandes durchaus bewusst und würdige die geleistete Arbeit in höchstem Maße.
Aber wenn du kritisierst, dass mit PHP 7 eine Chance verpasst worden wäre, und dann eine riesige Liste von Dingen präsentierst, die da alle noch reingehören sollten... das klingt nicht gerade so, als ob du akzeptierst, dass PHP so ist, wie es ist (und sich in einigen Punkten noch weiterentwickeln sollte), sondern dass PHP doch eigentlich noch mal schnell das alles hätte einbauen können.
Du weißt, warum PHP 6 gescheitert ist? Man baut nicht mal eben UTF-8-Unterstützung ein. In meiner täglichen Arbeit vermisse ich da jedenfalls nichts. Es gibt UTF-8-fähige Stringfunktionen, wenn man denn mal eine braucht.
Ja, PHP 6 ist auch an dem überambitionierten Ziel gescheitert UTF8-Support in die Sprache einzubetten. Das war ein katasrophaler Folgeschaden, den dieser frühe Designfehler nach sich gezogen hat. Heute ist PHP daher in diesem Punkt genauso weit wie vor PHP 6. Das ist schade und das kritisiere ich an der heutigen Version von PHP. Die Argumente haben sich seither ja nicht geändert.
Mir fehlt tatsächlich die Phantasie, mir vorzustellen, was UTF-8-Support über die bestehenden Stringfunktionen (mb_*) hinaus für einen nennenswerten Vorteil hätte. Ja, ich könnte mit
$string[2]auf das dritte Zeichen zugreifen, nicht auf das dritte Byte wie jetzt. Ich benutze/warte/entwickle derzeit keinerlei Code, bei dem das irgendwie relevant wäre. Und der ist überall komplett UTF-8-fähig.Grüße Sven
-
-
-
-