Uusi PHP-murre, koodinimeltään P ++, voitaisiin kehittää tiukemmaksi muunnelmaksi sen dynaamisesta edeltäjästä, edistyneemmillä ominaisuuksilla ja vähemmän matkatavaroilla.
Ehdotuksella, jonka PHP: n perustaja Zeev Suraski kelluu PHP-yhteisössä, olisi P ++ tai mikä tahansa sen nimi, elää PHP: n rinnalla, mutta ei sido PHP: n historiallinen filosofia. P ++ ei olisi haarukka, mutta se olisi luonnostaan tiukempi ja voisi olla rohkeampi taaksepäin yhteensopivuuden kanssa.
Elementit, joita nyt pidetään matkatavaroina, kuten lyhyet tunnisteet, voitaisiin poistaa, kun taas monimutkaiset ominaisuudet, erityisesti tiukasti kirjoitetuille kielille, kuten tiukat operaattorit tai muuttujat, voitaisiin lisätä lisäämättä samalla monimutkaisuutta PHP-murteeseen.
Kuten itse PHP, P ++ olisi pääasiassa palvelinpuolen verkkokehitystä varten. Suunnitellun PHP 8 -julkaisun odotetaan jo laajentavan PHP: tä verkkokehityksen ulkopuolelle, juuri oikea-aikaisen moottorin ja yhteentoimivuuden C / C ++ -kirjastojen kanssa.
Valtaosa PHP: n ja P ++: n koodeista olisi identtinen. Suurin osa koodista jaettaisiin PHP- ja P ++ -solmujen välillä sekä lähteessä että ajon aikana. Mutta heillä olisi erilaisia toteutuksia. Binaarit ovat identtisiä.
Vielä ei ole selvää, miten tiedosto merkitään P ++ -tiedostoksi. Sen yläosassa olisi todennäköisesti erityinen otsikko. Rakentajat voisivat myös löytää tapoja merkitä kokonaiset nimitilat P ++: ksi, joten kehysten ei tarvitse merkitä kutakin tiedostoa P ++: ksi.
Tietorakenteet, verkkopalvelinrajapinnat, tärkeimmät alijärjestelmät ja suurin osa kaikesta muusta ovat täsmälleen sama koodi riippumatta siitä, suoritetaanko tiedosto PHP: nä vai P ++. Silti kaksi versiota tietyistä koodikappaleista olisi säilytettävä. Ja P ++: lla on todennäköisesti ylimääräisiä tarkastuksia verrattuna PHP: hen. Kehittäjät voisivat sekoittaa PHP: tä ja P ++: ta samassa sovelluksessa. Molemmat murteet voidaan suorittaa yhdellä palvelimella.
Jos P ++ tapahtuu, se merkitsisi erilaista evoluutiota PHP: lle. Tiukkuus ja tyyppiin liittyvät ominaisuudet ovat todennäköisesti käytössä P ++: ssa. Aikaisempi yhteensopivuus taaksepäin pysyy PHP: ssä. Etuyhteydettömät ominaisuudet, kuten moottorin suorituskyvyn parantaminen tai laajennusten kehitys, olisivat käytettävissä sekä P ++: ssa että PHP: ssä.
Zuraski huomauttaa mahdollisista vaihtoehdoista P ++ -kielelle:
- Pysyminen dynaamisen PHP: n kanssa, jota tiukemman kielen kannattajat eivät hyväksy.
- Kehittyy kohti tiukempaa PHP: tä, jota ei voida hyväksyä dynaamisemman kielen kannattajille.
- Haaroittamalla koodipohjaa, nettotappio kaikille mukana oleville.
- Laaditaan ratkaisu, joka palvelee molempia yleisöjä, mitä P ++ -ehdotus yrittää.
P ++ -ehdotusta koskevat huolenaiheet ovat:
- PHP-koodin muuntaminen P ++: ksi ei olisi triviaali. Kuinka totta se on, riippuu siitä, mikä lopulta päätyy P ++: een.
- PHP-työkalut eivät tue P ++: ta. Mutta myyjien voi olla yksinkertaisempaa tukea P ++: ta kuin tukea rakeisia ilmoituksia () tai rajoittamatonta määrää painoksia.
- PHP-yhteensopivuuden rikkoutuminen. Mutta tekeminen uudella murteella pikemminkin kuin itse PHP: n rikkominen voisi olla miellyttävämpää.
P ++ eroaisi Facebookin PHP: lle rakennetusta Hack-kielestä seuraavalla tavalla:
- Hackin kehitti yksi yritys.
- Hackillä ja mukana olevalla HHVM-virtuaalikoneella ei ole PHP: n suurta jakeluautoa.
