En ny dialekt av PHP, kodenavnet P ++, kan utvikles som en strengere variant av dens dynamiske forgjenger, med mer avanserte funksjoner og mindre bagasje.
Forslaget, som ble drevet i PHP-samfunnet av PHP-medstifter Zeev Suraski, ville ha P ++, eller hva det til slutt heter, leve ved siden av PHP, men ikke bundet av PHPs historiske filosofi. P ++ ville ikke være en gaffel, men det ville være iboende strengere og kunne være mer dristig med bakoverkompatibilitet.
Elementer som nå betraktes som "bagasje", for eksempel korte koder, kan fjernes mens komplekse funksjoner, spesielt de for strengt typede språk som strenge operatører eller typede variabler, kan legges til uten å innføre samme kompleksitet i PHP-dialekten.
I likhet med PHP selv, ville P ++ hovedsakelig være for webutvikling på serversiden. Den planlagte PHP 8-utgivelsen forventes allerede å utvide PHP utover nettutvikling, med en just-in-time motor og interoperabilitet med C / C ++ - biblioteker.
De aller fleste koder i PHP og P ++ ville være identiske. De fleste koder vil bli delt mellom PHP- og P ++ -noder både i kilde og ved kjøretid. Men de ville ha forskjellige implementeringer. Binærfiler vil være identiske.
Det som ikke er klart ennå, er hvordan en fil vil bli merket som en P ++ - fil. Det ville sannsynligvis ha en spesiell topptekst på toppen. Utbyggere kunne også finne måter å markere hele navneområder som P ++, slik at rammene ikke trenger å merke hver fil som P ++.
Datastrukturer, webservergrensesnitt, viktige delsystemer og mest alt annet vil være nøyaktig den samme koden uansett om en fil kjøres som PHP eller P ++. To versjoner av visse kodestykker må likevel opprettholdes. Og det er sannsynlig at P ++ har flere kontroller sammenlignet med PHP. Utviklere kan blande og matche PHP og P ++ i samme app. Begge dialektene kan kjøres på en enkelt server.
Hvis P ++ skjer, vil det bety en annen utvikling for PHP. Strenghet og type-relaterte funksjoner vil sannsynligvis gå i P ++. Bias for bakoverkompatibilitet forblir i PHP. Urelaterte funksjoner, som ytelsesforbedringer i motoren eller utvikling i utvidelser, vil være tilgjengelige i både P ++ og PHP.
Zuraski peker på mulige alternativer for P ++ språk:
- Holde seg med en dynamisk PHP, som ikke ville bli akseptert av talsmenn for et strengere språk.
- Utvikler seg mot en strengere PHP, ikke akseptabelt for tilhengere av et mer dynamisk språk.
- Forking av kodebasen, et nettotap for alle involverte.
- Utarbeide en løsning for å imøtekomme begge publikum, og det er det P ++ - forslaget forsøker.
Bekymringer for P ++ -forslaget inkluderer:
- Å konvertere PHP-kode til P ++ ville ikke være trivielt. Hvor sant det er, vil avhenge av hva som til slutt havner i P ++.
- PHP-verktøy støtter ikke P ++. Men det kan være enklere for leverandører å støtte P ++ i stedet for å støtte granular deklarere (s) eller et ubegrenset antall utgaver.
- Brudd på PHP-kompatibilitet. Men å gjøre det via en ny dialekt i stedet for å bryte PHP selv, kan være mer velsmakende.
P ++ vil skille seg fra Facebooks Hack-språk, som ble bygget på PHP, ved at:
- Hack ble utviklet av et enkelt selskap.
- Hack og den medfølgende HHVM virtuelle maskinen har ikke PHPs store distribusjonskjøretøy.
