En ny dialekt af PHP, kodenavnet P ++, kunne udvikles som en strengere variant af dens dynamiske forgænger med mere avancerede funktioner og mindre bagage.
Forslaget, der flydes i PHP-samfundet af PHP-medstifter Zeev Suraski, ville have P ++, eller hvad det i sidste ende kaldes, leve sammen med PHP, men ikke bundet af PHPs historiske filosofi. P ++ ville ikke være en gaffel, men det ville i sagens natur være strengere og kunne være mere dristigt med bagudkompatibilitet.
Elementer, der nu betragtes som "bagage", såsom korte tags, kunne fjernes, mens komplekse funktioner, især dem til strengt typede sprog som strenge operatorer eller typede variabler, kunne tilføjes uden at indføre den samme kompleksitet i PHP-dialekten.
Ligesom PHP selv ville P ++ overvejende være til webudvikling på serversiden. Den planlagte PHP 8-udgivelse forventes allerede at udvide PHP ud over webudvikling med en just-in-time motor og interoperabilitet med C / C ++ - biblioteker.
Langt størstedelen af koden i PHP og P ++ ville være identisk. De fleste koder deles mellem PHP og P ++ noder både i kilde og ved kørsel. Men de ville have forskellige implementeringer. Binærfiler er identiske.
Hvad der endnu ikke er klart, er, hvordan en fil vil blive markeret som en P ++ - fil. Det ville sandsynligvis have en særlig header øverst. Bygherrer kunne også finde måder at markere hele navneområder som P ++, så rammerne behøver ikke at markere hver fil som P ++.
Datastrukturer, webservergrænseflader, nøglesubsystemer og mest alt andet vil være nøjagtig den samme kode, uanset om en fil udføres som PHP eller P ++. To versioner af bestemte kodestykker skal stadig vedligeholdes. Og P ++ har sandsynligvis yderligere kontrol i forhold til PHP. Udviklere kunne blande og matche PHP og P ++ i samme app. Begge dialekter kunne køres på en enkelt server.
Hvis P ++ sker, ville det betyde en anden udvikling for PHP. Strenghed og type-relaterede funktioner vil sandsynligvis gå i P ++. Bias for bagudkompatibilitet forbliver i PHP. Ikke-relaterede funktioner, såsom forbedringer af ydeevnen i motoren eller udvikling i udvidelser, ville være tilgængelige i både P ++ og PHP.
Zuraski påpeger mulige muligheder for P ++ sprog:
- Opholder sig med en dynamisk PHP, som ikke ville blive accepteret af tilhængere af et strengere sprog.
- Udvikler sig mod en strengere PHP, ikke acceptabel for tilhængere af et mere dynamisk sprog.
- Forking af codebase, et nettotab for alle involverede.
- At udvikle en løsning til at imødekomme begge målgrupper, hvilket er, hvad P ++ - forslaget forsøger.
Bekymringer omkring P ++ -forslaget inkluderer:
- Konvertering af PHP-kode til P ++ ville ikke være trivielt. Hvor sandt det er, afhænger af, hvad der i sidste ende ender i P ++.
- PHP-værktøjer understøtter ikke P ++. Men det kan være enklere for leverandører at understøtte P ++ i stedet for at understøtte granular deklarere (s) eller et ubegrænset antal udgaver.
- Brud på PHP-kompatibilitet. Men at gøre det via en ny dialekt i stedet for at bryde PHP selv kunne være mere velsmagende.
P ++ adskiller sig fra Facebooks Hack-sprog, som blev bygget på PHP, ved at:
- Hack blev udviklet af et enkelt firma.
- Hack og den ledsagende virtuelle HHVM-maskine har ikke PHP's store distributionskøretøj.
