Iako ima brojne prednosti, kada dođe do većih zahteva php prikazuje svoje slabosti. Da ja shvatam da je najveća popularnost zbog postojanja jako velikog broja ugrađenih funkcija za sve i svašta, zbog opšte prisutnosti na 99% svih hosting paketa, znam da ima jako mnogo programera koji u njemu šljakaju, ali se meni jezik sve manje dopada.

Kada počnete da radite u php-u, prvo što primetite jeste da vrlo brzo moćete da napravite nešto korisno, nema deklaracije, definicije, pravila su vrlo slobodna, php radi automatske konverzije i sve ostalo, ma idealno. Ali…

Onda na red dolaze krupnije stvari, i shvatite da vaš kod liči na špagete (hvala Predragu Damjanoviću na poređenju) i ma kako vi poštovali vaš coding style dolazite u situaciju da više ne možete da pratite organizaciju projekta. Ok, idemo na OOP, sredićemo funkcije u klase, kontrolisaćemo ko šta poziva i ko šta mož?e da poziva. Ali đavola, sve do najnovijeg php5 (koji se dugo vremena neće naći na nivou popularnosti php4), trenutno neupotrebljivog za bilo kakv ozbiljan rad, OOP u php-u je, pa prava reč je smešan. Kakav je to OOP kada ne postoje privatni i javni deo klase, kada ne postoje pokazivači i reference? Dobro, hajde za ovaj prvi deo, recimo da pišemo kod tako da sigurno nećemo dopustiti sebi da odemo van interfejsa klase, već pazimo na private/public metode i vrednosti. Ali kako rešiti drugi problem? Recimo da imamo DB klasu. Ta klasa je potrebna iz Auth klase kako bi ista pročitala privilegije korisnika, a potrebna je i iz neke Navigation klase jer će ona učitavati odgovarajući kod zavisno od tražene stranice (Koji će verovatno koristiti metode DB klase). Nikakav problem, na prvi pogled. Imamo instancu DB klase, poš?aljemo je po referenci u Auth i u Navigation klasu i šta se onda desi? PHP-ev idiotski način prosleđivanja objekta po referenci izvršava konstruktor ponovo pri svakom prosleđivanju. E sada kako ne bismo upali u filelock (pošto naša DB klasa, jelte koristi tekstualne datoteke), mi iz konstruktora DB klase izdvajamo deo koda van klase, zatim iz metoda koji postavljaju upit, izdvajamo delove koji moraju da se prenose izmedju 2 instance DB klase kao globalne varijable koje čitamo i pišemo pomoću funkcija ne-članica klase. I šta na kraju dobijamo, pa opet špagete. Umesto da dobijemo black-box objekat DB, mi imamo klasu DB koja rasipa svoj kod na barem još tri mesta. Hajde dosta o objektima.

Kako stvari stoje sa kontrolom programa? Pa dovoljno je pomenuti da je php typesafe i sve je jasno koliko kontrole može da se implementira. One glupave is_* funkcije su nepredvidive, tj treba uvek prvo njih proveriti kako se ponašaju, a tek onda proveravati program.

Sledeće, mrežno programiranje… PHP je skript jezik koji se najčešće koristi za izradu raznoraznih dinamičkih sajtova zar ne? Pa onda bi valjda trebao da ima dobro implementiran socket interfejs, da omogući kvalitetno mrežno programiranje. Ali… Recimo da trebamo da pošaljemo udaljenoj skripti neke podatke, zar nije logično da postoji način da ta udaljena skripta pročita sve podatke koje smo joj poslali? Funkcija fread() to radi međutim tek od php-a verzije 4.3.0 i novije. Za starije verzije php interpretatora ili moramo ubaciti kontrolnu sekvencu koja imitira EOF (iako select() funkcija u BSD sockets interfejsu itekako može da očita EOF u poslatoj komunikaciji sa servera - “man select”) ili postaviti da fread() pročita nekih 10MB podataka, a pošto će web server prekinuti komunikaciju čim pošalje podatke (manje od 10MB) php neće čitati doveka (jer gubi deskriptor socket-a koji se gasi po prekidu konekcije).

Može ovde sigurno još mnogo toga da se nabraja, ali nakon dužeg rada sa php-om verujem da svi shvate idiotizam php-gtk projekta. Pored toliko kvalitetnih jezika poput C++-a ( ;) ), praviti php sa klijentskim GUI-jem je čista perverzija. Nekada sam se bunio kada neko sa podsmehom pomene php. Sada, pa hm, ćutim. Nadam se da će kada php uđe u stable, mnogi hosting provajderi prihvatiti novu verziju, mada bez otkrivanja nekog velikog sigurnosnog propusta u php4, do toga teško mož doći, prvenstveno zbog kompatibilnosti loše napisanog php4 koda, koji iz ko zna kog razloga upravo koristi one gore felerične reference.