Vývoj PHP – cesta správným směrem?

PHP se stalo jedním z nejpopulárnějších systémů pro tvorbu dynamických webových stránek. Proto každá jeho nová verze vzbuzuje vlnu očekávání. Nejinak tomu bylo i před vydáním PHP5. V tomto článku bych chtěl shrnout své nepříliš pozitivní dojmy z této novinky a směřování platformy PHP vůbec.

Systém PHP se od své první verze s primitivní funkcionalitou vyvinul v mocný programovací nástroj s masivní oblibou a podporou vývojářů. Jeho obliba je natolik vysoká, že je považován svým způsobem za standard a málokterý hosting (včetně freehostingu) jej nepodporuje. V poslední době se zdvihnul velký povyk okolo nejnovější verze PHP s pořadovým číslem 5. Nebudu se zabývat změnami, které tato novinka přinesla (na Intervalu si o tom můžete přečíst třeba v článku Objekty v PHP5 nebo Další novinky v PHP5), ale pokusím se zde podat argumenty, proč pátou verzi PHP nepovažuji za krok správným směrem.

Směřování PHP

Dobrou vlastností každého vývojáře je mimo jiné i správná volba prostředků. Úměrně velikosti celého projektu a některým dalším požadavkům musí být zvolena správná programovací platforma a jazyk, protože špatná volba v této fázi vývoje může velmi negativně ovlivnit celý proces a hlavně náklady, o které jde především. Proto je například nevhodné použít pro malý web pracující nad nevelkou databází řešení založené na .NET, protože by to bylo ono pověstné „braní kanónu na vrabce“. Zcela analogicky pro rozsáhlé robustní projekty není PHP tím nejlepším řešením, ale nabízí se zde například právě zmiňovaný .NET nebo řešení založená na Javě. Zvolení takové platformy má sice za následek větší počáteční náklady, které se však mnohonásobně vyplatí v pokročilejších fázích tvorby systému.

Základním problémem PHP jsou nesplnitelné ambice jeho tvůrců a bohužel i jeho některých „tvrdých“ fanoušků. Místo toho, aby si PHP upevňovalo svou vybudovanou pozici na poli malých až středních aplikací a opatrně zvažovalo každou úpravu, snaží se nesmyslně proniknout výše, kde však již kralují úplně jiná řešení. Podobně nesmyslné, až úsměvné mi připadají názory některých jedinců ve smyslu PHP stačí na jakýkoliv projekt. Výsledkem těchto snah však nemůže být nic jiného než kočkopes, který už přestává být úplně použitelným pro rychlý a efektivní vývoj menších aplikací a který ještě zdaleka není použitelný pro robustní systémy.

Zcela v duchu těchto ambicí byla vytvářena pátá verze jazyka PHP. Na úkor oprav mnohých chyb a nedostatků, kterými současné PHP dost trpí, byl značně rozšířen objektový model. Ovšem každý stavař vám řekne, že na nestabilních základech nelze postavit kvalitní stavbu. Podobný problém podle mě postihnul právě PHP.

Rozšíření objektového modelu

Jak již bylo řečeno, největších změn se dočkal objektový model. Přibyly modifikátory přístupu k atributům a metodám třídy (public, protected, private), možnost napsat vlastní destruktor, lepší podpora kopírování objektů a některé další možnosti, které mají PHP přiblížit objektovým jazykům jako je Java. Základní otázkou pro mě zůstává, je robustní objektový model skutečným přínosem pro PHP?

Jednou ze základních vlastností PHP je netypovost. Ta umožňuje použití specifických prostředků, které nemůže poskytnout jazyk s typovou kontrolou a naopak. Realizace objektových postupů v takovém jazyce je však značně limitována právě jeho netypovostí. Nedosáhneme například nikdy skutečného polymorfismu, protože metodám nelze předepsat typ parametru, který mají očekávat.

Objektově orientované programování má sice v PHP svůj význam, ale ten by měl být odvozován od skutečného určení tohoto jazyka. Objekty je určitě vhodné použít pro lepší organizaci zdrojového textu. Například většina z programátorů si časem vytvoří třídu pro zasílání dotazů na databázi (Zjednodušte si práci s MySQL). Taková třída obvykle zapouzdřuje nejen funkce PHP, ale i proměnné představující identifikátor připojení a výsledku dotazu jako své atributy. Tyto proměnné pak zbytečně neznečišťují globální názvový prostor, ale jsou zapouzdřeny v dané instanci takové třídy. Proto nemusíme při programování dávat pozor na to, že v proměnné $link máme uložen identifikátor připojení a že jej nesmíme přepsat. Toto základní využití objektů rozhodně považuji za správné a především výhodné. Zároveň se však domnívám, že zde někde se nachází strop využití objektového programováni v PHP.

OOP přineslo zcela nový pohled na koncepci programování. Tou se stala množina objektů (instancí tříd) specializovaných na řešení určitého problému, které spolu komunikují a implementují tak požadovanou funkčnost. Jejich životnost je různá, některé jsou použity pro vykonání určité činnosti a pak hned zrušeny, jiné žijí po celou dobu běhu aplikace. Lze tedy říci, že doba života objektů v paměti je shora omezena pouze dobou běhu aplikace. Životnost objektu v PHP je však mnohem limitovanější! Objekt existuje pouze v průběhu jediného požadavku. Tedy implementace objektových postupů v PHP vypadá přibližně takto:

Při každém novém požadavku se musí vytvářet celá objektová struktura a definovat stavy jednotlivých objektů. Navíc, pokud jsou některé třídy součástmi nějaké hierarchie (dědičnost, implementace), musí skript načíst a zpracovat celou tuto hierarchii. A to vše pro splnění značně omezeného úkolu, pro který je daný skript určen. Při dokončení skriptu mizí všechny tyto objekty v nenávratnu.

Určitou berličkou při řešení této situace by bylo použití serializace celé objektové struktury a její deserializace na začátku skriptu následujícího (na Intervalu se o ní můžete více dočíst ve článku PHP pro pokročilé – znovu třídy a objekty). Pak je ovšem vhodné se zamyslet nad použitím úplně jiné platformy, která lépe splňuje naše požadavky.

Cílem každého programátora píšícího v PHP by měl být skript, který co nejefektivněji vyřeší daný problém. Na základě výše uvedených argumentů si dovoluji tvrdit, že přílišný objektový přístup tomu zamezuje. Proto se mi nezdá správné, že vylepšení podpory objektů v PHP5 bylo věnováno nejvíce prostoru. Přitom mnohé problémy, které sužují PHP mnohem palčivěji, zůstaly nevyřešeny. A navíc přidáním objektové podpory vznikly některé další.

Podpora různých kódování řetězců.

Tohle je myslím nejpalčivější bolest PHP. Zatímco všechny moderní jazyky a platformy se snaží poskytnout co největší podporu pro různá kódování řetězců, PHP se staví do pozice mrtvého brouka. Pro vývojáře, kteří chtějí své aplikace používat v různých prostředích s různými jazyky, tak vyvstává skutečný problém, především v tu chvíli, kdy chtějí použít vícebytové kódování. Všechny standardní funkce PHP počítají s tím, že znak je kódován pomocí jediného bytu, což však nemusí být vždy pravda. PHP5 se tento problém snaží vyřešit pomocí knihovny iconv a jejích funkcí, která je nově přímou součástí PHP. Do skutečné nativní podpory různých kódování má však tato knihovna daleko.

Dodržování zásad při pojmenovávání

Vizitkou každého programátora je jeho kód. Nutnou podmínkou pro čistotu kódu je dodržování pojmenovacích konvencí pro třídy, metody a proměnné. Vývojáři PHP však stále přešlapují na místě a nejsou schopni dodržovat konvence ani na úrovni nativních funkcí. A tak můžeme i v páté verzi narazit třeba na funkci stripslashes() (všechnomalýmpísmenem) a hned vedle ní na strip_tags() (slova_oddělená_mezerníkem). Nové zmatení přichází s větší podporou objektového přístupu. A tak zde máme třídu mysqli (opět všechnomalýmpísmenem) pro zapouzdření připojení k databázi, zatímco třídy ze standardní knihovny SPL se již drží klasické konvence VšechnaSlovaVelkýmPísmenem.

Tento chaos přetrvává v PHP již velmi dlouhou dobu a každá nová verze jej pouze prohlubuje. Osobně bych byl všema deseti pro zažitou javovskou konvenci (každé slovo identifikátoru velkým písmenem, první písmeno velké u názvu třídy, jinak malé), ale nevadilo by mi, kdyby byla dodržována alespoň nějaká konvence!

Chaotická implementace výjimek

Další avizovanou novinkou v PHP5 je podpora výjimek známých z Javy nebo C++. Bohužel je v duchu celé pětkové verze nedotažená. PHP totiž neposkytuje hierarchii výjimek podobně jako moderní objektové jazyky, ale poskytuje pouze základní výjimku Exception. Navíc vzhledem k netypovosti PHP můžete pomocí klíčového slova throw vyhodit jakýkoli objekt, který s touto třídou nemusí mít absolutně nic společného.

Toto však není ten největší problém výjimek v PHP5. Mnohem horší je jejich podpora nativními funkcemi PHP. Je totiž nulová! Například bych naivně předpokládal, že funkce mysql_query při zadání syntakticky špatného dotazu vyhodí této situaci ekvivalentní výjimku, třeba SQLSyntaxException. Místo toho však tato funkce pouze vrátí hodnotu false. Zcela stejně tomu je u zbývajících funkcí.

Nabízí se tedy otázka, proč vlastně tvůrci implementovali možnost výjimek, když je pak sami nepodporují.

Ztracená příležitost

Jazyk PHP se podle mě začal ubírat směrem, který mu rozhodně neprospěje. Jeho tvůrci se snažili maximálně vylepšit objektový model jazyka, který nemůže být nikdy tak použitelný jako u Javy nebo C#, protože je silně limitován netypovostí PHP, ale zapomněli přitom na jiné problémy, které by potřebovaly rychlé a úplné řešení. Místo aby posílili PHP tam, kde je skutečně výborně použitelné (malé a střední aplikace s požadavkem na rychlost), marně se snaží konkurovat robustním platformám, které jsou však určeny na úplně jiný typ aplikací než PHP.

PHP je dnes jediným prakticky použitelným řešením pro menší aplikace, a proto jej budu k těmto účelům nadále používat. Pro velké aplikace, u kterých je objektový přístup dnes povinností, je však stále nutno volit jinou platformu, bez ohledu na novinky v páté verzi PHP.

Starší komentáře ke článku

Pokud máte zájem o starší komentáře k tomuto článku, naleznete je zde.