Neuer Zweig von PHP: P++, wagen Sie immer noch zu sagen, dass PHP eine schwach typisierte Sprache ist?

Zusammenfassung: Rasmus Lerdorf, der Begründer der PHP-Sprache, wurde 1968 geboren und wird dieses Jahr 51 Jahre alt. Er veröffentlichte PHP 1.0 im Jahr 1995 unter dem Namen Personal Home Page Tools. Sein Ruhm verblasste mit dem Rückgang der Suchfunktion von Yahoo.

1997 schlossen sich die israelischen Programmierer Zeev Suraski und Andi Gutmans der PHP-Sprachentwicklung der Zend Company an und veröffentlichten PHP 3, PHP 4, PHP 5. Beachten Sie, dass es kein PHP 6 und jetzt PHP 7 gibt. Zeev Suraski, geboren 1975, arbeitet seit 20 Jahren bei Zend. Vielleicht kann ich die Entwicklungsrichtung in der Sprache, Architektur und Bibliotheksarbeit nicht erkennen.

Vor ein paar Tagen Zeev Suraski gab seinen Rücktritt von Zend bekannt Die Branche war ziemlich überrascht PHP 7-Optimierungsentwickler Bruder Niao sagte, dass dies etwas gewesen sei schon lange geplant. Es stellt sich heraus, dass Zeev Suraski zurückgetreten ist, weil er P++ machen wollte. Was ist also P++? Er antwortete mit „P++ idea: FAQ“ und der Autor übersetzte den vollständigen Text.

Originalübersetzung:

Dies ist eine Mailingliste für internals@(internals@: interne PHP-Entwickler. Hier finden Sie häufig gestellte Fragen (FAQ) Klarstellungen zu in externen Beiträgen vorgeschlagenen Ideen (normalerweise zur Einreichung von RFCs und Freigabemitteilungen verwendet), die versuchen, viele der in nachfolgenden Diskussionen wiederholt angesprochenen Probleme anzugehen.

Hinweis: P++ ist ein temporärer Codename und kann sich in Zukunft ändern.

Was zum Teufel ist los?

Ich versuche, den langen E-Mail-Inhalt auf einige Punkte zusammenzufassen:

1. Es gibt zwei große Lager in der PHP-Welt. Der erste mag im Allgemeinen die Dynamik von PHP mit einer starken BC-Voreingenommenheit (BC: Abwärtskompatibilität, auch Abwärtskompatibilität genannt, kompatibel mit früheren Versionen, das heißt, aktualisierte Software muss die Kompatibilität alter Versionen berücksichtigen. Zum Beispiel Word of Office 2019 verwendet standardmäßig das .docx-Dateiformat, kann aber auch das .doc-Format von Office 2017/2013/2010 oder sogar 2003 öffnen. Das relative Konzept heißt FC, was Vorwärtskompatibilität bedeutet, was auch Vorwärtskompatibilität genannt wird Aufwärtskompatibilität, das heißt, die aktualisierte Software berücksichtigt zukünftige Kompatibilität. Dies ist normalerweise eine bestimmte Schnittstelle und Konvention in der Software, die auch in Zukunft befolgt wird, wobei ein besonderer Schwerpunkt auf Einfachheit liegt Eine weitere Präferenz besteht darin, den Ballast loszuwerden und eine strengere Sprache mit höheren Ebenen und komplexeren Funktionen zu verwenden.

2. Hier gibt es kein „richtig“ oder „falsch“. Beide Genres sind gültig und haben eine sehr engagierte Anhängerschaft. Allerdings ist es eine Herausforderung, eine Sprache zu schaffen, die beiden Lagern gerecht wird, und das ist eine ständige Quelle für Debatten über internals@.

3. Der Vorschlag besteht darin, einen neuen PHP-Dialekt (Codename P++) zu erstellen, der mit PHP koexistiert, aber nicht an die historische Philosophie hinter der Sprache gebunden ist. Mit anderen Worten, dieser neue Dialekt ist möglicherweise restriktiver Natur, kann die Abwärtskompatibilität mutiger beseitigen und Elemente entfernen, die als „Ballast“ gelten (z. B. kurze Tags), und komplexere Funktionen hinzufügen, insbesondere solche, die gut sind Geeignet für streng typisierte Sprachen, ohne die gleichen Komplexitäten wie PHP-Dialekte einzuführen.

4. Dies ist kein PHP-Codezweig. Die Codebasis wird dieselbe sein und die Entwickler, die daran arbeiten, werden dieselben sein. Der größte Teil des Codes ist derselbe. Lediglich bestimmte Unterschiede zwischen den beiden Dialekten werden unterschiedlich umgesetzt. Es ähnelt in gewisser Weise dem, was strict_types in PHP 7 gemacht hat, nur in einem größeren Maßstab.

Werden wir das wirklich tun, nur weil manche Leute nicht auf kurze Tags verzichten können?

Dies hat nichts mit kurzen Tags zu tun, „Veraltete kurze Tags RFC (RFC: Request for Comments), dem Hinzufügen von Sprachfunktionen und standardisierten Änderungsmanagementmethoden. Normalerweise, wenn neue Funktionen hinzugefügt werden, neu.“ „Funktionen werden RFCs vorgelegt und Beispiele gegeben. Nachdem das Änderungskomitee die Sprache bewertet und genehmigt hat, wird sie in den Implementierungsquellcode integriert und in die neue Version integriert.“ ist nicht die Hauptmotivation für diese Idee. Das Ziel dieses Vorschlags besteht darin, ehrgeiziger zu sein, eine klare Vision für PHP zu liefern und zu hoffen, die Spannungen zwischen den beiden Lagern endlich zu lösen, indem beiden Lagern das gegeben wird, was sie wollen.

Warum PHP forken?

Dies ist keine Gabelung. Die Codebasis wird genau dieselbe sein, sie wird von denselben Leuten entwickelt. Die Binärdateien sind genau die gleichen. Wenn Sie PHP installieren, installieren Sie auch P++ und umgekehrt. Mit derselben Binärdatei werden PHP-, P++- oder kombinierte PHP/P++-Anwendungen ausgeführt.

Obwohl nicht klar ist, wie eine Datei als P++-Datei „markiert“ wird, könnte es sich um eine Art spezielles Tag am Anfang der Datei handeln, zum Beispiel:

<?p++?>
<?php &#39;Hello, world!&#39;; ?>

Darüber hinaus haben wir Möglicherweise stellen Sie fest, dass der gesamte Namespace als P++ markiert ist, sodass das Framework nicht jede einzelne Datei explizit als P++ markieren muss.

Das bedeutet, dass sich unser Entwicklungsaufwand verdoppelt hat und die Anzahl der Mitwirkenden in internals@ bereits niedrig ist. Wie gehen wir damit um?

Zum Glück soll es nicht so sein (doppelte Arbeitsbelastung). Der Großteil des Codes wird zwischen dem PHP-Modus und dem P++-Modus gemeinsam genutzt – sowohl Quellcode als auch Laufzeit.

Unabhängig davon, ob es sich bei der ausgeführten Datei um eine PHP- oder P++-Datei handelt, sind die Datenstrukturen, Schlüsselsubsysteme, Erweiterungen, Webserverschnittstellen, OPcache und der gesamte andere Code genau derselbe Code. Der einzige zusätzliche Entwicklungsaufwand werden die Unterschiede zwischen PHP und P++ sein.

In der Tat bedeutet dies, dass wir zwei Versionen bestimmter Codeausschnitte verwalten müssen und hier und da einige if()-Anweisungen haben werden, da P++ im Vergleich zu PHP möglicherweise zusätzliche Prüfungen hat. Wenn wir jedoch auf eine strengere Version von PHP umsteigen wollen, müssen diese Elemente trotzdem eingeführt werden. Darüber hinaus empfehlen selbst diejenigen im strikten Lager nicht, auf eine zukünftige strikte Version umzusteigen, ohne einen Migrationspfad anzugeben – tatsächlich ist der mit diesem Ansatz verbundene Aufwand ähnlich wie bei fast jedem anderen Ansatz.

Wenn wir auf das strengere PHP 8/9 umsteigen, warum entwickeln wir dann nicht einfach eine dauerhaft gewartete PHP 7.4-Langzeit-Wartungsversion?

Bei diesem Ansatz gibt es viele Probleme. Selbst wenn wir die Tatsache außer Acht lassen, dass dadurch das große dynamische Präferenzlager hängen bleibt – ohne jegliche Funktions- oder Leistungsaktualisierungen ist es aus Sicht des Entwicklungsaufwands unpraktisch. Dies unterscheidet sich von diesem Vorschlag, der tatsächlich eine De-facto-Abspaltung bedeutet.

Muss ich zwischen PHP und P++ wählen?

Ja und nein. Wie oben erwähnt, wenn Sie einen installieren, haben Sie auch den anderen, sodass Sie, was Anwendungen betrifft, beide Dialekte auf einem Server ausführen können. In der Praxis entscheiden sich Projekte und Einzelpersonen jedoch häufig für die eine oder andere Art und standardisieren sie, ähnlich wie bei strengen Typen.

Kann ich PHP und P++ in derselben Anwendung mischen?

Ja. Während wir den genauen Mechanismus bestimmen müssen, erfolgt die Angabe, ob der Code PHP oder P++ ist, auf Dateiebene und nicht auf der Anforderungsebene. Eine einzelne Ausführung (Anfrage) kann viele verschiedene Dateien laden, die aus beiden Dialekten stammen können. Code in PHP-Dateien verhält sich wie PHP-Semantik – und Code aus P++-Dateien verhält sich wie P++-Semantik. Dies ähnelt auch strict_types.

Auch wenn dies zunächst umständlich klingt, kann es durchaus praktische Anwendungsfälle geben. Beispielsweise verwendet eine PHP-Anwendung ein reines P++-Framework und umgekehrt. Für diejenigen, die mit C und C++ vertraut sind, ist dies etwas ähnlich.

Bedeutet das, dass PHP nicht mehr weiterentwickelt wird? Werden alle neuen Funktionen in P++ verfügbar sein?

Nein, es bedeutet nur, dass es anders ausgehen wird. Strenge und typbezogene Funktionen sind möglicherweise nur in P++ verfügbar und dürfen nur in P++-Dateien verwendet werden. Die Abwärtskompatibilitätsverzerrung bleibt in PHP bestehen (dies bedeutet nicht, dass die Abwärtskompatibilität niemals unterbrochen wird, sondern nur, dass es für jeden solchen Fall einen guten ROI-Fall geben muss).

Allerdings sind Funktionen, die nichts damit zu tun haben, wie z. B. Verbesserungen der Engine-Leistung (wie JIT), die Entwicklung von Erweiterungen oder neue asynchrone Funktionen, sowohl für PHP als auch für P++ verfügbar.

Was sind die Vorteile dieser Methode?

Diese Methode hat viele Vorteile. Erstens bietet es eine gute Lösung für beide Lager von internals@. Wer den dynamischen Charakter von PHP bevorzugt, kann es behalten, wer eine strenger typisierte Sprache bevorzugt, kann es auch ohne PHP-Einschränkungen bekommen. Die Alternative ist ein Nullsummenspiel, bei dem ein Sieg des einen Lagers eine Niederlage des anderen Lagers bedeutet und umgekehrt.

Neben der Entwicklung einer guten technischen Lösung, die es uns ermöglicht, unser gesamtes Publikum mit minimalem Aufwand zu unterstützen, würde dies auch einen wichtigen Streitpunkt über internals@ in den letzten Jahren beenden.

Auch wenn es sich bei den meisten Lesern dieses Dokuments wahrscheinlich um Techniker handelt, sollte beachtet werden, dass der Start von P++ von einem neuen Ausgangspunkt unabhängig von der Vergangenheit enorme Positionierungs- und Markenvorteile haben kann. Unternehmen, Entwicklungsmanager und einzelne Entwickler, die kein PHP verwenden, bemerken eher die Einführung von P++ als die Einführung von PHP 8.0 oder PHP 9.0.

Gehen wir nicht das Risiko ein, die Nutzerbasis zu spalten?

In gewisser Weise sind wir es. Dies ist jedoch kein Fehler in der Idee, sondern eine Manifestation der bereits bestehenden Realität.

Wie oben erwähnt, gibt es viele Leute da draußen, die die dynamische Natur von PHP mögen und davor zurückschrecken, es immer typorientierter zu machen.

In der Zwischenzeit schaut sich eine andere Gruppe von Leuten PHP an und denkt sich: „Warum wird es so langsam, dass ich diesen dynamischen Unsinn endlich aufgeben werde?“

Hier gibt es kein Richtig oder Falsch. Beide Ansichten sind gültig. Als wir nach möglichen Lösungen suchten, um diese beiden widersprüchlichen Standpunkte zu überbrücken, waren nicht viele verfügbar:

1. Bleiben Sie bei dynamischem PHP. Dies wird von Befürwortern einer strengeren Sprache nicht akzeptiert.

2. Entwickeln Sie sich in Richtung striktes PHP. Befürworter dynamischer Sprachen werden dies nicht akzeptieren.

3. Forken Sie die Codebasis. Egal wie es gemacht wird, es ist eine Nettoverlustoption für alle Teilnehmer. Dies hat keinen technischen Vorteil, und selbst wenn wir es wollten (was wir nicht tun), hätten wir nicht genügend Mitwirkende, um es zu tun.

4. Überlegen Sie sich kreative Lösungen, um den Bedürfnissen beider Zielgruppen gerecht zu werden. Genau das versucht dieser Vorschlag zu erreichen. Es gewährleistet eine dauerhafte Interoperabilität zwischen den beiden Dialekten und sorgt gleichzeitig dafür, dass das Projekt selbst einheitlich bleibt. Obwohl dies einen gewissen Grad an Fragmentierung aufweisen wird, ist es immer noch das Minimum, das möglich ist, um die Hauptbedürfnisse aller zu erfüllen.

Wie unterscheidet sich das von der Idee von Nikita (einem Sprecher auf internals@, der vorschlug, der Version Features hinzuzufügen. Übrigens ist die amerikanische TV-Serie „Nikita“ sehenswert .) Version?

Es gibt viele Ähnlichkeiten zwischen diesen beiden Ideen, aber es gibt auch einige wesentliche Unterschiede. Bitte beachten Sie, dass dies auf einem begrenzten Verständnis der Versionsmethodik basiert und daher Teile fehlen, ungenau oder falsch sein können.

1. In diesem Vorschlag besteht das klare Ziel, das aktuelle dynamisch typisierte PHP als langfristigen, vollständig unterstützten, gleichberechtigten Peer-Dialekt beizubehalten. Der Release-Ansatz behandelt das aktuelle Verhalten als „Legacy“. Dies bedeutet, dass davon abgeraten (verwendet) und dann irgendwann veraltet und entfernt werden kann.

2. Die Startstrategie ist völlig anders. Der P++-Vorschlag zielt darauf ab, sich zunächst auf kompatibilitätsschädigende Elemente wie strikte Operationen, Änderungen an der Typkonvertierungslogik, Array-Index-Handhabung, erforderliche Variablendeklarationen usw. zu konzentrieren und diese in der ersten Ausgabe von P++ bereitzustellen. Der Zweck besteht darin, es neuen Projekten/Frameworks zu ermöglichen, neu zu beginnen, ohne zu wissen, dass sie in ein oder zwei Jahren möglicherweise umfassend umgeschrieben werden müssen, wenn weitere Kompatibilitätsänderungen eingeführt werden. Der Versionierungsvorschlag scheint kein solches Ziel zu haben, sondern zielt stattdessen darauf ab, Elemente in PHP schrittweise hinzuzufügen/zu ändern.

3. Bezogen auf den Rollout-Ansatz erlaubt der Versionierungsansatz nicht nur zwei Dialekte, sondern eine beliebige Anzahl von Dialekten. Möglicherweise haben wir einen PHP2020-Dialekt sowie einen PHP2022-Dialekt und einen PHP2027-Dialekt. Wenn wir sie alle behalten würden, könnte dies unsere Wartungskomplexität tatsächlich erhöhen.

4. Der Vorschlag erwähnt auch unterschiedliche Strategien zur Aufhebung der Abwärtskompatibilität für PHP vs. P++ (konservativ vs. aggressiv), während das Versionierungsschema dieses Thema möglicherweise überhaupt nicht berührt.

5. Der Versionsvorschlag stimmt hinsichtlich Positionierung/Marketing nicht genau mit diesem Vorschlag überein.

Es ist wichtig zu beachten, dass sich diese beiden Ideen nicht unbedingt gegenseitig ausschließen. Wir können P++ einführen und Versionen verwenden, um es zu verbessern, insbesondere wenn es sich als schwierig erweist, alle wichtigen Änderungen in die erste Ausgabe von P++ unterzubringen.

Was sind die Herausforderungen?

Es gab keinen Mangel an Herausforderungen, bevor wir unsere erste P++-Anwendung ausführen konnten.

1. Wir brauchen Unterstützung. Das bedeutet, dass Menschen auf beiden Seiten des Ganges ihre Träume, PHP vollständig dynamisch oder vollständig typisiert zu machen, aufgeben und diejenigen ignorieren müssen, die anders denken als sie. Dies scheint eine sehr große Herausforderung zu sein.

2. Um erfolgreich zu sein, sollte die erste Version von P++ alle oder zumindest die meisten kompatibilitätsschädigenden Änderungen von PHP bewältigen, sodass Entwickler, die (möglicherweise recht schmerzhaft) wechseln, nicht noch einmal darauf zurückgreifen müssen ihren Code umgestalten. Einige äußerten Bedenken, dass unsere Entwickler aufgrund der begrenzten Fähigkeiten möglicherweise zu optimistisch seien und nicht in der Lage seien, eine Ausgabe zu veröffentlichen. Sobald wir eine bessere Vorstellung davon haben, worum es in der Liste geht, müssen wir diese bewerten. Beachten Sie, dass dies nicht bedeutet, dass wir jede Idee, die wir für P++ haben könnten, in der ersten Ausgabe umsetzen müssen, sondern nur, dass wir Elemente priorisieren sollten, die eine Menge Umschreiben des Endbenutzercodes auslösen, und dies versuchen sollten, bevor wir uns in unserer ersten Ausgabe mit ihnen befassen .

3. Die größte Herausforderung besteht natürlich darin, einen vernünftigen Namen für diesen neuen Dialekt zu finden.

Verwandte Empfehlungen:

1. Warum ist PHP die beste Sprache der Welt?

2.

PHP ist nicht mehr zehn Jahre alt alt

3.

PHP 7.4 wird voraussichtlich im Dezember 2019 veröffentlicht

4. Warum werden wir das auch weiterhin tun? PHP verwenden?

5.

Warum hacken Programmierer PHP? Die chinesische PHP-Website hat etwas zu sagen!