PHP plus: P ++ Vorschlag würde einen strengeren Dialekt schaffen

Ein neuer PHP-Dialekt mit dem Codenamen P ++ könnte als strengere Variante seines dynamischen Vorgängers mit erweiterten Funktionen und weniger Gepäck entwickelt werden.

Der Vorschlag, der von PHP-Mitbegründer Zeev Suraski in der PHP-Community veröffentlicht wurde, würde P ++ oder wie auch immer es letztendlich genannt wird, neben PHP leben, aber nicht an die historische Philosophie von PHP gebunden sein. P ++ wäre keine Gabelung, aber es wäre von Natur aus strenger und könnte gewagter mit Abwärtskompatibilität sein.

Elemente, die jetzt als „Gepäck“ betrachtet werden, wie z. B. kurze Tags, könnten entfernt werden, während komplexe Funktionen, insbesondere solche für streng typisierte Sprachen wie strenge Operatoren oder typisierte Variablen, hinzugefügt werden könnten, ohne dass der PHP-Dialekt dieselbe Komplexität aufweist.

Wie PHP selbst wäre P ++ vorwiegend für die serverseitige Webentwicklung gedacht. Die geplante PHP 8-Version soll PHP bereits über die Webentwicklung hinaus erweitern, mit einer Just-in-Time-Engine und Interoperabilität mit C / C ++ - Bibliotheken.

Die überwiegende Mehrheit des Codes in PHP und P ++ wäre identisch. Der meiste Code wird sowohl in der Quelle als auch zur Laufzeit zwischen PHP- und P ++ - Knoten geteilt. Aber sie hätten unterschiedliche Implementierungen. Binärdateien sind identisch.

Was noch nicht klar ist, ist, wie eine Datei als P ++ - Datei markiert wird. Es hätte wahrscheinlich einen speziellen Header oben. Builder könnten auch Möglichkeiten finden, ganze Namespaces als P ++ zu markieren, sodass die Frameworks nicht jede Datei als P ++ markieren müssen.

Datenstrukturen, Webserver-Schnittstellen, wichtige Subsysteme und fast alles andere sind genau derselbe Code, unabhängig davon, ob eine Datei als PHP oder P ++ ausgeführt wird. Dennoch müssten zwei Versionen bestimmter Codeteile beibehalten werden. Und P ++ wird im Vergleich zu PHP wahrscheinlich zusätzliche Prüfungen haben. Entwickler können PHP und P ++ in derselben App kombinieren. Beide Dialekte können auf einem einzigen Server ausgeführt werden.

Wenn P ++ passiert, würde dies eine andere Entwicklung für PHP bedeuten. Strenge und typbezogene Funktionen werden wahrscheinlich in P ++ verwendet. Die Abweichung für die Abwärtskompatibilität bleibt in PHP erhalten. Nicht verwandte Funktionen wie Leistungsverbesserungen in der Engine oder Entwicklungen bei Erweiterungen wären sowohl in P ++ als auch in PHP verfügbar.

Zuraski weist auf mögliche Optionen für die P ++ - Sprache hin:

  • Bleiben Sie bei einem dynamischen PHP, das von Befürwortern einer strengeren Sprache nicht akzeptiert würde.
  • Entwicklung zu einem strengeren PHP, das für Befürworter einer dynamischeren Sprache nicht akzeptabel ist.
  • Forking the Codebase, ein Nettoverlust für alle Beteiligten.
  • Entwicklung einer Lösung für beide Zielgruppen, wie es der P ++ - Vorschlag versucht.

Zu den Bedenken hinsichtlich des P ++ - Vorschlags gehören:

  • Das Konvertieren von PHP-Code in P ++ wäre nicht trivial. Wie wahr das ist, hängt davon ab, was letztendlich in P ++ endet.
  • PHP-Tools unterstützen P ++ nicht. Für Anbieter könnte es jedoch einfacher sein, P ++ zu unterstützen, als granulare Deklarationen () oder eine unbegrenzte Anzahl von Editionen zu unterstützen.
  • Unterbrechung der PHP-Kompatibilität. Aber dies über einen neuen Dialekt zu tun, anstatt PHP selbst zu brechen, könnte schmackhafter sein.

P ++ würde sich von Facebooks Hack-Sprache, die auf PHP basiert, darin unterscheiden:

  • Hack wurde von einer einzigen Firma entwickelt.
  • Hack und die dazugehörige virtuelle HHVM-Maschine verfügen nicht über das große Distributionsfahrzeug von PHP.