PHP plus: la proposta P ++ creerebbe un dialetto più rigoroso

Un nuovo dialetto di PHP, nome in codice P ++, potrebbe essere sviluppato come una variante più rigida del suo predecessore dinamico, con funzionalità più avanzate e meno bagagli.

La proposta, lanciata nella comunità PHP dal cofondatore di PHP Zeev Suraski, avrebbe P ++, o come si chiamerà alla fine, che vive accanto a PHP ma non è vincolato dalla filosofia storica di PHP. P ++ non sarebbe un fork, ma sarebbe intrinsecamente più rigoroso e potrebbe essere più audace con la retrocompatibilità.

Gli elementi ora considerati "bagaglio", come i tag brevi, potrebbero essere rimossi mentre le funzionalità complesse, specialmente quelle per linguaggi strettamente tipizzati come operatori rigorosi o variabili tipizzate, potrebbero essere aggiunte senza introdurre la stessa complessità al dialetto PHP.

Come PHP stesso, P ++ sarebbe principalmente per lo sviluppo web lato server. La prevista versione di PHP 8 dovrebbe già estendere PHP oltre lo sviluppo web, con un motore just-in-time e interoperabilità con le librerie C / C ++.

La stragrande maggioranza del codice in PHP e P ++ sarebbe identica. La maggior parte del codice verrebbe condivisa tra i nodi PHP e P ++ sia nel codice sorgente che in fase di runtime. Ma avrebbero implementazioni diverse. I binari saranno identici.

Ciò che non è ancora chiaro è come un file verrebbe contrassegnato come file P ++. Probabilmente avrebbe un'intestazione speciale in alto. I costruttori potrebbero anche trovare modi per contrassegnare interi spazi dei nomi come P ++, quindi i framework non devono contrassegnare ogni file come P ++.

Strutture dati, interfacce di server web, sottosistemi chiave e quasi tutto il resto sarà esattamente lo stesso codice indipendentemente dal fatto che un file venga eseguito come PHP o P ++. Tuttavia, dovrebbero essere mantenute due versioni di alcune parti di codice. E è probabile che P ++ abbia controlli aggiuntivi rispetto a PHP. Gli sviluppatori possono combinare e abbinare PHP e P ++ nella stessa app. Entrambi i dialetti potrebbero essere eseguiti su un singolo server.

Se accade P ++, significherebbe un'evoluzione diversa per PHP. È probabile che la rigidità e le funzionalità relative al tipo siano disponibili in P ++. Il bias per la retrocompatibilità rimarrà in PHP. Funzionalità non correlate, come miglioramenti delle prestazioni nel motore o sviluppi nelle estensioni, sarebbero disponibili sia in P ++ che in PHP.

Zuraski indica potenziali opzioni per il linguaggio P ++:

  • Rimanere con un PHP dinamico, che non sarebbe accettato dai fautori di un linguaggio più rigoroso.
  • Evoluzione verso un PHP più rigoroso, non accettabile per i sostenitori di un linguaggio più dinamico.
  • Biforcando la base del codice, una perdita netta per tutti i soggetti coinvolti.
  • Ideare una soluzione per soddisfare entrambi i tipi di pubblico, che è ciò che la proposta di P ++ tenta.

Le preoccupazioni sulla proposta P ++ includono:

  • Convertire il codice PHP in P ++ non sarebbe banale. Quanto ciò sia vero dipenderà da ciò che alla fine finisce in P ++.
  • Gli strumenti PHP non supporteranno P ++. Ma potrebbe essere più semplice per i fornitori supportare P ++ piuttosto che supportare dichiarazioni granulari o un numero illimitato di edizioni.
  • Rottura della compatibilità con PHP. Ma farlo tramite un nuovo dialetto piuttosto che rompere lo stesso PHP potrebbe essere più appetibile.

P ++ differirebbe dal linguaggio Hack di Facebook, che è stato costruito su PHP, in quanto:

  • Hack è stato sviluppato da una singola azienda.
  • Hack e la macchina virtuale HHVM che l'accompagna non hanno il grande veicolo di distribuzione di PHP.