Vývoj PHP 6
Školení, která pořádám 
Článek vyšel v rámci PHP okénka na serveru Root.cz.
Sotva vyšlo PHP 5.1 a v kuchyni už se delší dobu vaří další velká verze. Skoro všichni významní vývojáři jádra PHP se 11. a 12. listopadu 2005 sešli na konferenci v Paříži a probrali, jakým směrem se má ubírat vývoj PHP 6. Derick Rethans z toho vytvořil precizní závěry a já zase nabízím jejich souhrn.
Unicode
Asi nejméně kontroverzní jsou změny v Unicode, které má být hlavní novinkou PHP 6 a o kterém už jsem stručně psal.
- To, zda se má Unicode interně používat, nepůjde určit při každém požadavku, ale pouze v
php.ini(1.1). - Kromě stávajících kódování bude možné určit také kódování názvů souborů, protože různé systémy používají různá kódování (1.5).
- Novinkou pro mě je, že přestože interní kódování PHP 6 bude UTF-16, tak jeden znak bude moci zabírat dva nebo čtyři bajty (budou podporovány i znaky s kódem nad 65535). Kvůli tomu by byly operace pro přístup k jednotlivým znakům pomalé a bude pravděpodobně nutné implementovat nějakou cache (1.7). Když už to tak je, kladu si otázku, proč vlastně interní kódování nebude UTF-8, které pravděpodobně bude převažovat na vstupu a výstupu – ušetřilo by se tím mnoho zbytečných konverzí.
- Pro chyby při převodu kódování bude vytvořena nová úroveň chyb (1.10).
Odstraněné vlastnosti
Spoustě lidí spadne kámen ze srdce a spoustě lidí se ztíží přechod na novou verzi odstraněním některých vlastností.
- Zmizí direktivy register_globals (2.1), magic_quotes_gpc, magic_quotes_runtime (2.2), safe_mode (2.3), zend.ze1_compatibility_mode (2.5) a register_long_arrays (2.11).
- Zrušena bude i možnost vyskočit z proměnlivého počtu cyklů divokou konstrukcí
break $var(2.14). - Nad odstraněním doporučované syntaxe
{}pro přístup ke znakům řetězce (4.5) jsem si už posteskl, nicméně vzhledem k bouřlivé odezvě to bude ještě předmětem dalších jednání. Uvidíme, jak to nakonec dopadne.
Zachované obraty
Některé sporné obraty naproti tomu budou zachovány:
- Vynucení reference při volání funkce vyvolá E_STRICT místo E_NOTICE, var zůstane aliasem pro public a varování zmizí a přiřazení new referencí zůstane E_STRICT (2.4).
- Direktiva open_basedir přežije (2.7).
- Funkce dl bude přesunuta do SAPI, ve kterých dává smysl (momentálně CLI) (2.8).
- Třídy nadále bude možné definovat podmíněně (2.10) a zůstanou i staré konstruktory – podivné chování PHP 4, kdy se metoda rodiče stala konstruktorem potomka, pokud měla stejné jméno, už není ani v PHP 5 (2.12).
- U funkcí se nadále nebude rozlišovat velikost písmen, ale použití nesprávné velikosti pravděpodobně vyvolá E_STRICT (2.13).
- Zápis do nedeklarované vlastnosti objektu nadále nevyvolá žádnou chybu (5.7) a zápis prvku do neinicializovaného pole zmíněn není, zůstane tedy spolu s bezpečnostními riziky (zmírněnými zakázáním register_globals) a těžko odhalitelnými chybami (posílenými definitivním nerozdělením operátorů pro přístup ke znakům řetězce a prvkům pole) bez jakéhokoliv varování.
- Zahájení PHP bloku nadále bude možné pomocí krátkého
<?,syntaxe<%naopak bude spolu s direktivou asp_tags odstraněna,<?php=přidáno nebude a blok bude možné ukončit pouze značkou odpovídající té, kterou byl zahájen (6.7). Z toho mi vyplývá, že syntaxe<script language="php">zůstane zachována, přestože to není explicitně uvedeno.
Přidané novinky
Do jazyka přibudou i některé často diskutované novinky:
- Vznikne typ int64, typ int zůstane platformově závislý (4.1), ale jestli se na tento typ bude převádět i při překročení velikosti čísla, zatím nevím.
- Příkaz goto, o kterém se také vášnivě debatovalo, se do jazyka dostane, ale vzhledem k zásadním omezením (nebude možné skákat dovnitř bloků kódu a bude možné skákat pouze směrem vpřed) se pro něj použije syntaxe
break label(4.2). Myslím, že to je vhodný kompromis použitelný pro ošetření chyb a těžko zneužitelný k používání ve stylu Basicu. - U vášnivě probírané konstrukce ifsetor ještě definitivní rozhodnutí nepadlo, jisté je zatím pouze to, že u ternárního operátoru bude možné vynechat prostřední část (4.3).
- V konstrukci foreach bude možné místo hodnoty používat funkci list (4.4). Párkrát by se mi tato konstrukce bývala hodila, dokonce čas od času zkouším, jestli v jazyce náhodou už není, vzhledem k jednořádkové náhradě to ale samozřejmě není nic zásadního.
- Uvnitř operátoru
[]bude možné používat složitější výrazy stejně jako u funkcí substr a array_slice (4.5). U řetězců proti tomu nic nemám, ale už se „těším“ na zmatky, které vyplynou z toho, že[]u pole bude moci vrátit kromě jednoho prvku také pole obsahující jeho část. - Za zásadní omyl považují změnu výchozí hodnoty parametru funkce microtime (4.10). Připomínám, že před PHP 5 se tato funkce volala bez parametru a vracela řetězec. V PHP 5 byl přidán nepovinný parametr zajišťující, že funkce vrátí desetinné číslo, s výchozí hodnotou způsobující původní chování. V PHP 6 se má výchozí hodnota tohoto parametru změnit tak, aby funkce bez parametru vracela desetinné číslo. Vývojáři to obhajují tím, že nejčastější použití funkce vracející řetězec ho stejně převádí na číslo a tento kód zůstane funkční (s jednou E_NOTICE navíc). Co ale ostatní použití funkce? Co když chce někdo třeba jenom desetinnou část a volá funkci bez parametru? Jednoduchá odpověď – v PHP 6 kód bez jakékoliv výstrahy přestane fungovat. Navíc mi není úplně jasné, jaký přínos tato změna přinese – o něco hezčí budoucí kód za cenu znefunkčnění mnoha skriptů myslím nestojí.
- Konstrukce self:: se vždy vztahuje ke třídě, ve které je použitá. Problém to může být u potomků, kdy by se často hodilo, aby se vztahovala ke třídě, přes kterou jsme se k self v rodiči dostali. Z toho důvodu bude zavedena nová konstrukce static:: (nebo možná this::), která tuto funkčnost zajistí (5.4).
- Jmenné prostory se do PHP nakonec pravděpodobně dostanou, ale jejich přesná podoba ještě bude dořešena (5.6).
- Statické volání nestatické metody vyvolá místo E_STRICT rovnou E_ERROR (5.10).
- Z projektu Hardened PHP se do PHP převezmou některé opravy. Asi nejvýznamnější změnou bude vznik nové direktivy allow_url_include, která bude ovlivňovat používání vzdálených souborů při vkládání PHP kódu (6.2). Pokud nicméně zůstane zachovaná možnost používat ostatní wrappery, bezpečnostní riziko se zmírní jen částečně.
- Chyby produkované jednotlivými rozšířeními budou zrevidovány a ve většině případů nahrazeny za E_WARNING nebo novou chybu E_RECOVERABLE_ERROR. Z té bude možné se vzpamatovat v případě, že bude ošetřena (6.4).
- Úroveň chyb E_STRICT se stane součástí konstanty E_ALL, ale výchozí nastavení zůstane
E_ALL & ~E_NOTICE, takže chyby E_STRICT ve výchozím nastavení zobrazovány budou, ale E_NOTICE ne (6.6). Zvláštní.
Zamítnuté novinky
Další novinky se naopak do jazyka nedostanou:
- Nebude umožněn průchod polem bez přiřazování hodnot do proměnné (4.7).
- Na své si nepřijdou ani příznivci pojmenovaných parametrů funkcí (4.8).
- Pořadí parametrů jednotlivých funkcí bude nadále začátečníkům činit problémy (4.9). Vývojáři jsou sice toho názoru, že to je u interních funkcí v podstatě konzistentní, ale nevzali v úvahu funkce pro práci s regulárními výrazy, které mají pořadí parametrů obráceně. Kromě toho funkce str_replace také přijímá prohledávaný řetězec až jako třetí parametr a ne jako první, jak je to zvykem v databázích a jak to má i strpos. I tak jsem rád, že k žádné změně nedojde, přeházení parametrů by způsobilo nedozírné zmatky a to i v případě, že by bylo doprovázeno např. přejmenováním funkcí na
str_*. - Při použití objektu v kontextu řetězce se volá metoda __toString. Pro použití v kontextu jiných primitivních typů nové magické metody nevzniknou a nadále se vždy bude volat tato (5.5).
- Type-hinting je nyní možné používat u parametrů, nově bude zaveden i u návratových hodnot funkcí, naopak nebude zaveden u vlastností. Syntaxe bude ještě zvolena, osobně se mi nejvíc líbí
function &ObjectName funcname()(5.8). Napovídání primitivních typů zmíněno není, takže v jazyce ani nadále s největší pravděpodobností nebude. - Nevznikne ani delegování metod rozhraní (5.12).
- Interní PHP funkce ani nadále nebudou vyvolávat výjimky, protože překlad jednotlivých úrovní chyb lze na výjimky snadno zajistit již od jejich uvedení (6.5).
Závěr
Většinu změn je určitě možné hodnotit pozitivně. Unicode je nesporným přínosem, byť bude nutné chování jednotlivých kódování stejně jako u databází nejprve pečlivě nastudovat. Pozitivně lze hodnotit i odstranění konfiguračních direktiv, které ve většině případů hlavně u začínajících programátorů způsobovaly víc zmatku než užitku. Některé změny mi ale připadají poněkud samoúčelné ve snaze jazyk vyčistit, ovšem za cenu pomalého a bolestného přechodu. Je s podivem, že při pohledu na pomalý přechod na PHP 5 (způsobenou ale hlavně důležitou změnou objektového modelu) se vývojáři chtějí pouštět do takových kousků jako je zbytečná změna výchozího hodnoty parametru u podružné funkce nebo odstranění čtyři roky doporučované syntaxe na úkor té, která byla označena jako zastaralá. Snaha o vyčištění jazyka se tak podle mého názoru ubírá ne zcela správným směrem – řada programátorů by spíše uvítala upozornění na potenciálně nebezpečné chování (jako je přiřazování prvků do neinicializovaného pole nebo do nedeklarovaných vlastností) nebo větší jednoznačnost jazyka (rozlišením operátorů pro přístup ke znakům řetězce a prvkům pole), zkrátka jeho lepší předvídatelnost. Místo toho ale např. dojde k tomu, že spolu se sjednocením parsování parametrů funkcí (všimněte si, že v současných verzích např. wordwrap("abc", "b") informaci o špatném typu parametrů vypíše, ale substr("abc", "b") ne) bude chybová hláška o nepřevoditelnosti na správný typ potlačena.
Cesta do vydání PHP 6 je nicméně ještě dlouhá a za tu dobu se ještě může leccos změnit.
Diskuse
ATom:
Škoda, že se neuvažuje o klíčovém slovu u vlastností objektu, které by zabránilo jejich serializaci. Tedy obdobě transient z Javy. Tohle mi dost chybí.Megaloman:
Pokud jde o směřování PHPčka, mohlo se udělat mnohem víc, namátkou:Nekonzistentní pojmenování funkcí - pro začátek by stačilo vytvořit konzistentní systém názvů funkcí a ponechat původní jako aliasy (pro zpětnou kompatibilitu).
Unicode - proč UTF-16 a ne UTF-8?
Rekurze - základy programování...
Zlepšení práce s datovými typy - zavedl bych možnost (ne povinnost) explicitně uvádět datový typ, jako u jiných vyšších jazyků.
A celkově by prospělo mít nějaký konkrétní cíl, kam směřovat, než jen reagovat na požadavky komunity, i když to je samozřejmě potřeba. Takhle to působí mírně chaoticky.
Kromě toho doufám, že dojde k mírnému zrychlení...
Jakub Vrána 
:
UTF-16 proto, že ho používá knihovna ICU, kterou PHP využívá. V našich zeměpisných šířkách by by bylo lepší UTF-8, ale v Asii je zase lepší UTF-16.
Co máš na mysli výkřikem "Rekurze"?
Možnost uvádět datový typ by leckdo uvítal, já jsem to jako Proof-of-Concept udělal: http://php.vrana.cz/napovidani-skalarnich-typu.php (ne, že by to bylo v praxi použitelné). Ale je asi pravda, že do dynamicky typovaného jazyka napovídání typů nepatří.
Na zrychlení bych nesázel.
Jakub Vrána : 
David Grudl:
Ke zrychlení skutečně dojde! První verze PHP 6 bude na aktuálním HW běžet značně rychleji, než první verze PHP 5 na aktuálním HW.
David Grudl: Jakub Vrána :
Já jsem to pochopil jako zrychlení vývoje, ale ono to spíš opravdu bylo o výkonu. Závěr je nicméně stejný.
Jakub Vrána : 
Ondra:
Prominte mi malé rýpnutí, ale článek je z 5.12.2005? Jak dlouho může trvat přepsat haldy funkcí do UTF-16....
Zvu vás na článek uvedený v URL.
Ondra: 
Insolvenční Ondra:
Tak máme dalšího půl roku pryč, a jediné reálně nasaditelné PHP 6 je zde:
http://bazen-shop.cz/zbozi/400/tepelne-ce…-6-elektron/
Nicméně. Spíše ze setrvačnosti jsem začal dělat jeden projekt (insolvenční rejstřík) na PHP, a se zlou jsem se potázal. Webová služba ISIR vrací výsledky v UTF, a pracovat s ní z PHP bylo opravdu za trest.
Insolvenční Ondra: Diskuse je zrušena z důvodu spamu.
© 2005-2024 