PHP 5 - konečně!

Jazyk PHP se před pár dny dočkal vydání své páté verze. Za sebe můžu říct jen: hurá, hurá, hurá! Nejradši bych byl, kdybych se zítra probudil, a na všech serverech na světě, co PHP používají, byla nainstalována nová verze a já ji tak mohl používat bez obav, že výsledná aplikace poběží jen na mém počítači.

Popisovat novinky páté verze se mi tu zdá zbytečné, nejlepší je přečíst si vše v originále. Nová verze jazyka spolu s vylepšenými knihovnami řeší takřka všechny problémy a omezení, na která jsem kdy při vývoji velkých (= přes 10 000 řádků objektového kódu) aplikací v PHP narazil. A ty, které neřeší, kvůli zpětné kompatibilitě ani řešit nemůže (např. nekonzistentnost knihovny funkcí). Mimochodem, vůbec mi nevadí, že se PHP 5 značně přiblížilo Javě – ba právě naopak.

Nu, zbývá jen doufat v co nejrychlejší nasazení nové verze na hostingových serverech. A troufl bych si tvrdit, že do roka a do dne už PHP 5 bude stejně běžné, jako je dnes PHP 4.

Jul 17, 2004 – 10:54

Comments

Lada Prosek
Lada Prosek
Ahoj Davide,
k PHP 5 bych mel par poznamek ;-) Tvoje nadseni nesdilim.

Nejdriv z pohledu PHP programatora: PHP je mix spousty jazyku, ktery vubec nepusobi konzistentne. Nema zadnou normu/standard. Jeho dokumentace se sestava z manualu, ktery obsahuje neuplne a casto nepravdive (ve smyslu konfliktu s jazykem indukovanym tou implementaci) informaci.

To lze ilustrovat napriklad tim, ze ten dokument 'Changes in PHP 5/Zend Engine II', ktery linkujes z clanku, je vlastne jediny popis tech novinek - hlavne objektoveho modelu, ktery oni vyprodukovali. A i v tak strucnem clanku lze najit veci, ktere neplati. Namatkou hned na zacatku vidim: "Protected member variables can be accessed in classes extending the class they are declared in..." Pravda je takova, ze protected member variables jsou pristupne z deklarujici tridy, vsech podtrid (do ted OK), ale i ze vsech nadtrid. Pro metody totez.

Ted z pohledu vnitrnosti PHP: PHP je napsane v C (ne C++), coz je pro tak velky projekt rozhodne spatna volba. Zdrojaky PHP by se mely ukazovat jako priklad toho, jak se nema programovat. Komentare jsou hodne ridke, naprosta vetsina kodu je uplne nekomentovana. Takze ta spousta bugu, ktera v PHP je, je jednoduse dusledek toho jejich stylu. A pokud to od zakladu neprepisou, tak se tech chyb nikdy nezbavi. Oni to pisou jako nejaky operacni system nebo co. Na kazdem kroku nejaka 'optimalizace' typu "protoze plati techhle dvacetosm podminek, tak se mi ten vysledek vejde do toho sameho bufferu jako vstup, takze nadeklaruju sest pointeru, kteryma po tom budu jezdit a usetrim si jednu alokaci, hura, to jsem ale coder!" O tom, jak jsou takovehle zoufalosti error-prone, neni snad pochyb...

Zaverem: PHP (a to ani verze 5) podle meho nazoru neni vubec vhodne pro nasazeni do produkcniho prostredi. Mne prijde, ze je to porad na urovni nejakeho studentskeho projektu...
David Majda
Ahoj Láďo,

moje nadšení pramení z toho, že v PHP prostě dělat musím, a tak vítám každé zlepšení. Ani nevíš, jak moc mi chybí klíčová slova "private" a "abstract", vyjímky (na ty jsem si dokonce v PHP4 naspal vlastní emulaci - aspoň na základní věci), properties a __autoload.

Na 90% hostingových serverů bohužel v nejbližší době jiná volba než PHP+MySQL nebude. Jsem si dobře vědom limitů tohoto jazyka, nekonzistentnosti atd. - však v něm dělám skoro denně dva nebo tři roky, a ne zrovna malé aplikace (největší má okolo 25 000 řádků a během prázdnin se toto číslo dost možná vyšplhá na 30 000). Vidím dobře, proč třeba banky mají své systémy v Javě nebo teď nově v .NETu.

Ty to zas vidíš zevnitř, jakožto tvůrce alternativní implementace jazyka. Pak samozřejmě narazíš na spoustu chyb, rozporností a dalších věcí, které většině aplikačních programátorů, včetně mě, uniknou.

Co se zdrojáků týče, tak nemám pocit, že by C byla špatná volba. PHP není příliš "velký" jazyk a výhody C++ se podle mě u tohoto typu projektu příliš neprojeví. "Objektovitost" kódu - ve smyslu organizace věcí do struktur a funkcí, které s nimi manipulují - dokážeš v céčku udělat bez problémů taky a u ostatních objektových věcí (dědičnost, polymorfismus,...) mě moc nenapadá, kde by se tam použily. A STL, což je další významná věc v C++, jsem zatím neviděl použitou vůbec v žádném produkčním zdrojáku, co jsem četl.

Mimochdem, snad všechny interprety jazyků ze stejné třídy jazyků jako PHP (namátkou JavaScript, Python, Perl, Ruby) jsou psané v céčku. A jsou to většinou jazyky, které vznikly v době, kdy už C++ bylo na rozumné úrovni, takže ho tvůrci mohli při implementaci použít.

Strukturování kódu je jiná věc. I v céčku jde psát hezky - když jsem se tak před rokem začetl do céčkového zdrojáku interpretu JavaScriptu v Mozille, tak jsem celkem rozuměl, i když komentáře byly celkem sporadické. Co se PHP týče, tak se s tebou nebudu pouštět do diskuze, protože zdroják jsem viděl jenom "letem světem", když jsem neměl nějaký večer zrovna co dělat, a ty ho dokážeš zhodnotit jistě líp.

K optimalizacím: To je dost diskutabilní téma, protože na vytížených serverech je každá alokace navíc znát. Osobně bych se do toho nepustil bez důkladného podložení všech změn funkcionálními a regresními testy - ty se zrovna u programovacího jazyka dají tvořit strašeně snadno (narozdíl třeba od GUI apliakcí). Ale opět platí - ty do toho asi teď vidíš líp a víš dobře, jak velké zhůvěřilosti tam páchají :-)

Co se nasazení do produkčního prostředí týče, nedá se říct než: pozdě, už se stalo. Evoluce vybírá podle úplně jiných měřítek, než je "elegance", "konzistence" a "vhodnost". Přednost dává flexibilitě a schopnosti nějak vyřešit nejpalčivější momentální problém. Koukni se na samotné HTML - jaký je to bordel, prohlížeče si s ním dělají co chtějí, kompatibilita s nimi stojí strašného úsilí... ale je to dnes dost možná nejrozšířenější platforma na tvorbu aplikací. Viděl jsi někdy objektový model Flashe, nejrozšířenějšího produktu své ktegorie? Radši ho ani vidět nechtěj, je to šílenost. Prosadí se prostě technologie, která ve své době řeší jeden konkrétní problém, ale její zobecnění a rozšíření většinou kvůli chatrným základům dopadne katastrofálně.

Podívej se na přírodní evoluci - její výsledky (třeba my), mají taky k dokonalosti rozdodně dost daleko, a jsou stejě jako to PHPko slepenec věcí, které "tak nějak dohromady fungují", ale je lepší do toho moc nešťourat. A zdá se, že tenhle "něco jako přírodní zákon" platí pro všechny druhy evoluce (tj. i technickou) a jen tak se nezmění.

P.S.: Tohle je asi nejdelší komentář, co jsem v životě napsal :-)
Lada Prosek
Lada Prosek
Zkusim nejak ospravedlnit svoje tvrzeni, ze C++ by byla pro implementace interpretu lepsi volba. Mas pravdu, ze v C je mozne si udelat nejake zapouzdreni apod. sam, ale krome, rekneme, prehlednejsiho kodu tim nic neziskas. Dulezite informace, jako: "pred dealokaci teto struktury je potreba uvolnit take pamet, na kterou ukazuje tento jeji field" zustanou v komentarich (nebo v pripade PHP nebudou nikde). Naproti v C++ tuhle informaci muzes napsat primo do kodu, kdyz napises destruktor, a nikdy se Ti nestane, ze bys uvolnil strukturu spatne. Kdyz se kod napise v C++, je podle meho nazoru mene nachylny k chybam. A treba zrovna ta sprava pameti je pro serverove aplikace pomerne dulezita vec.

S tou evolucni teorii naprosto souhlasim :-)
David Majda
No, zrovna tohle mi neprijde jako problem. Staci kdyz mam ke kazde strukture dvojici funkci, ktere pouzivam na jeji alokaci/dealokaci a dusledne je vsude pouzivam.

Priklad analogickeho kodu v C++ a C:

class ANested {
// some data
};

class A {
public:
ANested *field;
A () {
field = new ANested();
// ...naplneni fieldu
}

~A() {
delete field;
}
};

=========================================

struct BNested {
// some data
};

struct B {
BNested *field;
};

B* b_create() {
B *result;

result = (B*)malloc(sizeof(B));
result->field = bnested_create();
// ...naplneni fieldu

return result;
}

void b_destroy(B* b) {
bnested_destroy(b->field);
free(b);
}

// fce bnested_create a bnested_destroy si uz dovedes predstavit

Krom veci souvisejicich s jazykem (malloc x new apod.) zde v expresivite kodu nevidim zadny rozdil.
Lada Prosek
Lada Prosek
No to je prave v tom "dusledne je vsude pouzivam". Kdyz neco pises sam, tak to v pohode zvladnes, ale kdyz na necem velkem dela vic lidi, tak to zacina byt problem. Nekdo muze zapomenout dealokacni funkci pouzit a kompilator nic nepozna. Destruktor proste zapomenout pouzit nelze.
David Majda
OK, uznávám, že v tomhle bodě máš pravdu a je to plus pro C++.

Dost to celé ale spíš IMHO souvisí s celkovou organizací práce. Spoustu podobných chyb (čarování s pointery, zda je reference weak nebo ne, různé "vlastnění se" objektů) totiž C++ nezachytí taky nebo možná jen s použitím různých smart pointerů, reference countingu a podobných opičáren. A v tom případě thyle "opičárny" kód podle mě spíš znepřehlední, než že by pomohly.

K té organizaci práce: Např. v mé oblíbené Mozille se do hlavního vývojového stromu nedostane žádný kód, aniž by ho kromě tvůrce nezkontrolovali nejméně dva další kompetentní (= v dané oblasti kódu se vyznající) vývojáři. Tak se podobný typ chyb, jaké tu naznačuješ, lehce odchytí. U kódu tak složitého jako Mozilla je tahle revize před check-inem naprostá nutnost. Předpokládám, že u PHP se něco takového vůbec nevede...
Martin Koníček
Martin Koníček
Láďo, myslím že ohledně jazyka nemáš moc pravdu. I když je PHP nadevše špinavý jazyk, dá se v něm programovat přinejmenším elegantně a rychle řešit problémy.

Když se člověk podívá na takové JSP, je to bezvadné řešení, ale strašně zdlouhavé. Nikdo dneska nepředpokládá, že webová aplikace by měla běžet za 10 let, navíc požadavky se pak změní.

Když se dostaneme k praktičnosti jazyka, zjistíš, že v PHP je vývoj aplikací extrémě rychlý, rychlost při ptimalizacích je relativně slušná, možnosti jazyka vysoké a při důkladném testování to prostě bude fungovat stejně dobře jak JSP.

Když mi někdo řekn,eže v špinavém jazyku nejdou pstá dobré programy, řeknu v čem je napsána bugzilla? Enterprise produkt a je napsaný v Perlu, v jednom z nejšpinavějších jazyků na světe, ale funguje sakra dobře a o to všem jde.

2Majda: Vůbec nechápu, jak může mít tvá aplikace 25 000 řádků kódu, to netestuješ? Já na 200 řádcích svého kódu v průměru najdu 100 chyb, ale pak to šlape jako hodinky, myslím že občas je lepší oželit nějakou tu funkčnost nad tím, že každá feature je promyšlená maximálně do detailu
David Majda
[7] Popravdě řečeno o té rychlosti programování a flexibilitě PHP jsem sem chtěl taky něco napsat, ale už k tomu nějak nedošlo. Je to určitě jedna z největších výhod PHP, dostatčně vyvažujících nedostatky.

Mám k tomu ještě pár poznámek, ale ty si schován do nějakého dalšího článku (až si to pořádně v hlavě sesumíruju).

K té 25K aplikaci (mimochodem je to pro Univerzitu Karlovu, v budoucnu součást jejího informačního systému): Klíčem k malé chybovitosti je důsledná modularizace kódu - nemíchat HTML layout, databáze a business logiku do sebe. Dost pomáhá objektovost kódu.

Krom toho mám napsanou jednu velkou testovací sadu dat a skritpty v JavaScriptu, které projdou jednotlivé sekce aplikace, proklikají formuláře, otestují reakce na chyby atd. Je to celé modulárně udělané, tj. můžu spustit test na jednu oblast nebo na celou apliakci. Taky o tom asi v budoucnu něco napíšu, protože jsem samozřejmě hrdý na to, jak jsem to vymyslel :-)

Ale upřímně řečeno sám se divím, že to celé vůbec funguje a problémů s vývojem a rozšiřováním je zatím minimum.

Každopádně tahle konkrétní aplikace je už na hranici, za kterou bych už radši použil zmiňované JSP. Striktnější jazyk by tady pomohl ve vychytávání chyb plynoucích z nemožnosti pamatovat si detaily o celém projektu najednou.
dgx
dgx
[7] ve 200 řádcích kódu si klidně těch 100 chyb dovolit můžeš, ale až budeš jednou (třeba) psát aplikace s 25 tisíci řádky, nemělo by chyb být víc než 10 ;-)
David Majda
[10] Neprošvihl, jen jsem se k tomu nějak nedostal. Navíc teď už si nejsem moc jistý, jestli vůbec něco napíšu, protože už jsem o rok dál a vidím na tom systému spoustu nedostatků, takže se s tím už nechci zas tak chlubit. Uvidíme :)

Add comment

It is not possible to add comments to posts older than one month.