nicht angemeldet
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.