phpFashion

Lze pomocí regulárních výrazů parsovat HTML?

Pojďme jednou provždy rozlousknout tuhle věčnou otázku, která rozděluje komunitu programátorů. Rozhodl jsem se ponořit do temných vod regulárních výrazů, abych přinesl odpověď (spoiler: ano, je to možné).

Takže, co vlastně HTML dokument obsahuje? Jde o mix textu, entit, značek, komentářů a speciální značky doctype. Prozkoumejme nejprve každou ingredienci zvlášť.

Entity

Základem HTML stránky je text, který tvoří obyčejné znaky a speciální sekvence zvané HTML entity. Ty mohou být buď pojmenované, jako je   pro nezlomitelnou mezeru, nebo číselné, a to buď v desítkovém   nebo šestnáctkovém   formátu. Regulární výraz, který zachytí HTML entitu, by vypadal takto:

(?<entity>
	&
	(
		[a-z][a-z0-9]+     # pojmenovaná entita
		|
		\#\d+              # desítkové číslo
		|
		\#x[0-9a-f]+       # hexadecimální číslo
	)
	;
)

Všechny regulární výrazy jsou zapsány v režimu extended, ignorují velikost písmen a tečka představuje jakýkoliv znak. Tj. modifikátor six.

Značky

Tyto ikonické prvky dělají HTML tím čím je. Tag začíná <, následuje název tagu, možná sada atributů a uzavírá se > nebo />. Atributy mohou mít volitelnou hodnotu a ta může být uvozena do dvojitých, jednoduchých nebo žádných uvozovek. Regulární výraz zachytávající atribut by vypadal takto:

(?<attribute>
	\s+                         # alespoň jeden bílý znak před atributem
	<a href="#fns" class="footnote">[\s&quot;&#039;&lt;&gt;=`/]</a>+               # název atributu
	(
		\s* = \s*               # rovnítko před hodnotou
		(
			"                   # hodnota uzavřená ve dvojitých uvozovkách
				(
					<a href="#fn" class="footnote">[&quot;]</a>        # libovolný znak kromě dvojité uvozovky
					|
					(?&entity)  # nebo HTML entita
				)*
			"
			|
			'                   # hodnota uzavřená v jednoduchých uvozovkách
				(
					<a href="#fn" class="footnote">[&#039;]</a>        # libovolný znak kromě uvozovky
					|
					(?&entity)  # nebo HTML entita
				)*
			'
			|
			<a href="#fns" class="footnote">[\s&quot;&#039;&lt;&gt;=`]</a>+         # hodnota bez uvozovek
		)
	)?                           # hodnota je volitelná
)

Všimněte si, že se odvolávám na pojmenovanou skupinu entity definovanou dříve.

Elementy

Element může představovat jak samostatná značka (tzv. prázdný element), tak značky párové. Existuje pevný výčet jmen prázdných elementů, podle kterých je rozeznáme. Regulární výraz pro jejich zachytávání by vypadal takto:

(?<void_element>
	<                  # začátek značky
	(                  # název elementu
		img|hr|br|input|meta|area|embed|keygen|source|base|col
		|link|param|basefont|frame|isindex|wbr|command|track
	)
	(?&attribute)*     # volitelné atributy
	\s*
	/?                 # volitelné /
	>                  # konec značky
)

Ostatní značky jsou tedy párové a zachytí je tento regulární výraz (používám v něm odvolávku na skupinu content, kterou teprve nadefinujeme):

(?<element>
	<                  # počáteční značka
	(?<element_name>
		[a-z]<a href="#fns" class="footnote">[\s/&gt;]</a>*  # název elementu
	)
	(?&attribute)*     # volitelné atributy
	\s*
	>                  # konec počáteční značky
	(?&content)*
	</                 # koncová značka
	(?P=element_name)  # zopakujeme název elementu
	\s*
	>                  # konec koncové značky
)

Speciálním případem jsou elementy jako <script>, jejichž obsah se musí zpracovávat odlišně od ostatních elementů:

(?<special_element>
	<                  # počáteční značka
	(?<special_element_name>
		script|style|textarea|title  # název elementu
	)
	(?&attribute)*     # volitelné atributy
	\s*
	>                  # konec počáteční značky
	(?>                # atomická skupina
		.*?            # nejmenší možný počet jakýchkoliv znaků
		</             # koncová značka
		(?P=special_element_name)
	)
	\s*
	>                  # konec koncové značky
)

Líný kvantifikátor .*? zajistí, že se výraz zastaví u první ukončovací sekvence, a atomická skupina zajistí, že toto zastavení bude definitivní.

Komentáře

Typický HTML komentář začíná sekvencí <!-- a končí sekvencí -->. Regulární výraz pro HTML komentáře může vypadat takto:

(?<comment>
	<!--
	(?>           # atomická skupina
		.*?       # nejmenší možný počet jakýchkoliv znaků
		-->
	)
)

Líný kvantifikátor .*? opět zajistí, že se výraz zastaví u první ukončovací sekvence, a atomická skupina zajistí, že toto zastavení bude definitivní.

Doctype

Jde o historický relikt, který dnes existuje jen proto, aby přepnul prohlížeč do tzv. standardního režimu. Obvykle vypadá jako <!doctype html>, ale může obsahovat i další znaky. Zde je regulární výraz, který jej zachytí:

(?<doctype>
	<!doctype
	\s
	<a href="#fn" class="footnote">[&gt;]</a>*         # jakékoliv znaky kromě '>'
	>
)

Dejme to dohromady

Když máme hotové regulární výrazy zachytávající každou část HTML, je čas vytvořit výraz pro celý HTML 5 dokument:

\s*
(?&doctype)?              # volitelný doctype
(?<content>
	(?&void_element)      # prázdný element
	|
	(?&special_element)   # speciální element
	|
	(?&element)           # párový element
	|
	(?&comment)           # komentář
	|
	(?&entity)            # entita
	|
	<a href="#fn" class="footnote">[&lt;]</a>                  # znak
)*

Všechny části můžeme spojit do jednoho komplexního regulárního výrazu. Tohle je on, superhrdina mezi regulárními výrazy se schopností parsovat HTML 5.

Závěrečné poznámky

I když jsme si ukázali, že HTML 5 lze parsovat pomocí regulárních výrazů, uvedený příklad k ničemu užitečný není. Nepomůže vám se zpracováním HTML dokumentu. Vyláme si zuby u nevalidního dokumentu. Bude pomalý. A tak dále. V praxi se používají spíš reguláry jako je tento (pro hledání URL obrázků):

<img.+?src=["'](.+?)["'].*?>

Ale to je opravdu velmi nespolehlivé řešení, která vede k chybám. Tento regexp chybně matchuje třeba custom tagy jako například <imgs-tag src="image.jpg">, custom atributy jako <img data-src="custom info">, nebo selže, když atribut bude obsahovat uvozovku <img src="mcdonald's.jpg">. Proto je doporučeno používat specializované knihovny. Ve světě PHP máme smolíčka, protože rozšíření DOM podporuje pouze pravěké ztrouchnivělé HTML 4. Naštěstí PHP 8.4 slibuje parser pro HTML 5.

Když Copilot ztratí směr aneb oslava fušeřiny

Video od Microsoftu, které mělo být oslnivou ukázkou možností Copilota, je spíš tragikomickou prezentací úpadku programátorského řemesla.

Mluvím o tomto videu. Má demonstrovat možnosti GitHub Copilota, mimo jiné jak pomocí něj napsat regulární výraz pro vyhledávání značek <img> s třídou hero-image. Jenže už původní kód, který upravují, je děravý jako švýcarský sýr, já bych se za něj styděl. Copilot se nechá strhnout a místo opravy pokračuje ve stejném duchu.

Výsledkem je regulární výraz, který nezamýšleně matchuje i jiné třídy, jiné značky, jiné atributy a tak dále. Ba co víc, selže, pokud je atribut src uveden před class.

Píšu o tom, protože tato demonstrace fušeřiny, zejména vzhledem k oficiální povaze videa, je zarážející. Jak je možné, že si toho nevšiml ani jeden z prezentujících či jejich kolegů? Nebo si toho všimli a řekli si, že o nic nejde? To by bylo ještě smutnější. Výuka programování vyžaduje preciznost a důslednost, bez nichž se snadno mohou propagovat nesprávné praktiky. Video mělo být oslavou programátorského umění, ale já v něm vidím ponurou ukázku, jak se úroveň programátorského řemesla propadá do propasti nedbalosti.

Ale ať nejsem jenom negativní: je tam hezky ukázáno, jak funguje Copilot a v něm GPT, takže si je určitě pusťte 🙂

První kroky v OOP v PHP: Základy, které musíte znát

Chcete se ponořit do světa objektově orientovaného programování v PHP, ale nevíte, kde začít? Mám pro vás nového stručného průvodce OOP, který vás seznámí se všemi těmi pojmy, jako class, extends, private atd.

V průvodci se dozvíte, co je to:

• třída a objekt
• jmenné prostory
• dědičnost versus kompozice
• viditelnost
• klíčové slovo final
• statické vlastnosti, metody a konstanty
• rozhraní nebo abstraktní třída
• typová kontrola
• Fluent Interfaces
• traity
• a jak fungují výjimky

Průvodce si neklade za cíl udělat z vás mistry v psaní čistého kódu nebo podat zcela vyčerpávající informace. Jeho cílem je vás rychle seznámit se základními koncepty OOP v současném PHP a dát vám fakticky správné informace. Tedy poskytnout pevný základ, na kterém můžete dále stavět. Třeba aplikace v Nette.

Jako navazující čtení doporučuji podrobný průvodce světem správného návrhu kódu. Ten je přínosný i pro všechny, co PHP a objektově orientované programování ovládají.

Kompilační chyby v PHP: proč jsou stále problémem?

Programování v jazyce PHP byla vždycky trošku výzva, ale naštěstí prošlo mnohými změnami k lepšímu. Pamatujete na časy před verzí PHP 7, kdy skoro každá chyba znamenala fatal error, což aplikaci okamžitě ukončilo? V praxi to znamenalo, že jakákoli chyba mohla aplikaci zcela zastavit, aniž by programátor měl možnost ji zachytit a náležitě na ni reagovat. Nástroje jako Tracy využívaly magických triků, aby dokázaly takové chyby vizualizovat a logovat. Naštěstí s příchodem PHP 7 se tohle změnilo. Chyby nyní vyvolávají výjimky, jako jsou Error, TypeError a ParseError, které lze snadno zachytávat a ošetřit.

Avšak i v moderním PHP existuje slabé místo, kdy se chová stejně jako ve své páté verzi. Mluvím o chybách během kompilace. Ty nelze zachytit a okamžitě vedou k ukončení aplikace. Jedná se o chyby úrovně E_COMPILE_ERROR. PHP jich generuje na dvě stovky. Vzniká paradoxní situace, že když v PHP načteme soubor se syntaktickou chybou, což může být třeba chybějící středník, vyhodí zachytitelnou výjimku ParseError. Ovšem v případě, že kód je sice syntakticky v pořádku, leč obsahuje chybu odhalitelnou až při kompilaci (například dvě metody se stejným názvem), vyústí to ve fatální chybu, kterou zachytit nelze.

try {
	require 'cesta_k_souboru.php';
} catch (ParseError $e) {
	echo "Syntaktická chyba v PHP souboru";
}

Bohužel, kompilační chyby v PHP nemůžeme ověřit interně. Existovala funkce php_check_syntax(), která navzdory názvu odhalovala i kompilační chyby. Byla zavedena v PHP 5.0.0, ale záhy odstraněna ve verzi 5.0.4 a od té doby nikdy nebyla nahrazena. Pro ověření správnosti kódu se musíme spolehnout na linter z příkazové řádky:

php -l soubor.php

Z prostředí PHP lze ověřit kód uložený v proměnné $code třeba takto:

$code = '... PHP kód pro ověření ...';
$process = proc_open(
	PHP_BINARY . ' -l',
	[['pipe', 'r'], ['pipe', 'w'], ['pipe', 'w']],
	$pipes,
	null,
	null,
	['bypass_shell' => true],
);
fwrite($pipes[0], $code);
fclose($pipes[0]);
$error = stream_get_contents($pipes[1]);
if (proc_close($process) !== 0) {
	echo 'Chyba v PHP souboru: ' . $error;
}

Nicméně režie spouštění externího PHP procesu kvůli ověření jednoho souboru je docela velká. Ale dobrá zpráva přichází s verzí PHP 8.3, která přinese možnost ověřovat více souborů najednou:

php -l soubor1.php soubor2.php soubor3.php

Proč je operátor ?? holé neštěstí

Na operátor ?? se v PHP čekalo neskutečně dlouho, snad deset let. Dnes je mi ale líto, že se nečekalo déle.

• Počkej, cože? Deset let? Tak to přeháníš, ne?
• Opravdu. Začal se řešit v roce 2004, pod názvem „ifsetor“. A dostal se do PHP až v prosinci 2015 ve verzi 7.0. Takže téměř 12 let.
• Aha! Notyvole.

Škoda, že se nečekalo déle. Do současného PHP totiž nezapadá.

PHP počínaje verzí 7.0 udělalo neuvěřitelný posun ke striktnosti. Klíčové okamžiky:

• zavedení skalárních typů (které prošly jen tak tak)
• nulovost (od 7.1, null se stal důležitým a nahrazuje dřívější return false)
• příčetné porovnávání (od 8.0, nechápu, že to Nikicovi tak snadno prošlo, JavaScript musí závidět)
• zrušení dynamických properites (definitivní konec „Vránovského“ PHP)

Operátor ?? zjednodušil otravné:

isset($necoCo[$musimNapsatDvakrat]) ? $necoCo[$musimNapsatDvakrat] : 'default value'

na pouhé:

$pisu[$jednou] ?? 'default value'

Jenže udělal to v době, kdy potřeba používat isset() značně klesla. Dnes častěji počítáme s tím, že data, ke kterým přistupujeme, existují. A pokud neexistují, tak se o tom sakra chceme dozvědět.

Operátor ?? má ale vedlejší efekt a to schopnost detekovat null. Což je taky nejčastější důvod k jeho užití:

$len = $this->length ?? 'default value'

Bohužel zároveň zatajuje chyby. Zatajuje překlepy:

// vždy vrátí 'default value', víte proč?
$len = $this->lenght ?? 'default value'

Zkrátka ?? jsme dostali přesně ve chvíli, kdy bychom naopak nejvíc potřeboval zkrátit tohle:

`php
$necoCo[$musimNapsatDvakrat] === null
? ‚default value‘
: $necoCo[$musimNapsatDvakrat]
`

Bylo by úžasné, kdyby PHP 9.0 mělo odvahu chování operátoru ?? upravit k trošku větší striktnosti. Udělat z „isset operátoru“ opravdu „null coalesce operator“, jak se mimochodem oficiálně jmenuje.

S detekcí překlepů zamlčených operátorem ?? vám pomůže PHPStan s nastavením checkDynamicProperties: true.

Tabulátory místo mezer jako projev ohleduplnosti

Určitě už jste někdy narazili debatu „tabulátory vs. mezery“ pro odsazování. Polemika probíhá od nepaměti a oba tábory vyzdvihují své argumenty:

Tabulátory:

• odsazování je jejich účel
• menší soubory, protože odsazení zabírá jeden znak
• můžete si nastavit vlastní šířku odsazení (? k tomu se vrátíme)

Mezery:

• kód bude vypadat všude stejně a konzistence je klíčová
• vyhnete se možným problémům v prostředích citlivých na bílé znaky

Co když jde ale o víc než o osobní preference? ChaseMoskal nedávno zveřejnil na Redditu velmi podnětný příspěvek s názvem Nikdo nezmínil skutečný důvod, proč používat tabulátory místo mezer, který vám otevře oči.

Stěžejní důvod, proč používat tabulátory

Chase ve svém příspěvku popisuje zkušenost se zaváděním mezer na svém pracovišti a negativní dopady, které to mělo na spolupracovníky se zrakovým postižením.

Jeden z nich byl zvyklý používat šířku tabulátoru 1, aby se vyhnul velkým odsazením při použití obřího písma. Druhý používá šířku tabulátoru 8, protože mu nejlépe vyhovuje na ultraširokém monitoru. Pro oba však představuje kód s mezerami vážný problém, musí je převádět na tabulátory před čtením a zase zpátky na mezery před komitováním.

Pro nevidomé programátory, kteří používají braillské displeje, představuje každá mezera jednu braillskou buňkou. Pokud je tedy výchozí odsazení 4 mezery, odsazení 3. úrovně plýtvá 12 cennými braillskými buňkami ještě před začátkem kódu. Na 40buňkovém displeji, který se u notebooků používá nejčastěji, je to více než čtvrtina dostupných buněk, které jsou promrhány bez jakékoliv informace.

Nám se může přizpůsobení šířky odsazení zdát jako zbytečnost, jsou ale mezi námi programátoři, pro které je naprosto nezbytné. A to prostě nemůžeme ignorovat.

Tím, že budeme v našich projektech používat tabulátory, dáváme jim možnost tohoto přizpůsobení.

Nejdříve přístupnost, pak osobní preference

Jistě, nejde přesvědčit každého, aby se přiklonil na jednu či druhou stranu, jde-li o preference. Každý má své. A měli bychom být rádi za možnost volby.

Zároveň však musíme dbát na to, abychom zohledňovali všechny. Abychom respektovali odlišnosti a používali přístupné prostředky. Jakým je například znak tabulátor.

Myslím, že Chase to vystihl dokonale, když ve svém příspěvku uvedl, že „…neexistuje žádný protiargument, který by se jen blížil k tomu převážit potřeby přístupnosti našich spolupracovníků“.

Accessible first

Stejně jako při navrhování webů se vžila metodika „mobile first“, kdy se snažíme zajistit, aby každý, bez ohledu na zařízení, měl s vaším produktem skvělou user experience – měli bychom usilovat o „accessible first“ prostředí tím, že zajistíme, aby každý měl stejnou možnost pracovat s kódem, ať už v zaměstnání nebo na opensource projektu.

Pokud se tabulátory stanou výchozí volbou pro odsazování, odstraníme jednu bariéru. Spolupráce pak bude příjemná pro každého, bez ohledu na jeho schopnosti. Pokud budou mít všichni stejné možnosti, můžeme maximálně využít společný potenciál ❤️

Článek vychází z Default to tabs instead of spaces for an ‚accessible first‘ environment. Podobně přesvědčivý post jsem si přečetl v roce 2008 a ještě ten den změnil ve všech svých projektech mezery na tabulátory. Zůstala po tom stopa v Gitu, ale samotný článek už zmizel v propadlišti dějin.

Přidejte si značku {texy} do Latte

Knihovna Texy od verze 3.1.6 přidává podporu pro Latte 3 v podobě značky {texy}. Co umí a jak ji nasadit?

Značka {texy} představuje snadný způsob, jak v Latte šablonách psát přímo v syntaxi Texy:

{texy}
You Already Know the Syntax
----------

No kidding, you know Latte syntax already. **It is the same as PHP syntax.**
{/texy}

Stačí do Latte nainstalovat rozšíření a předat mu objekt Texy nakonfigurovaný podle potřeby:

$texy = new Texy\Texy;
$latte = new Latte\Engine;
$latte->addExtension(new Texy\Bridges\Latte\TexyExtension($texy));

Pokud je mezi značkami {texy}...{/texy} statický text, tak se přeloží pomocí Texy už během kompilace šablony a výsledek do ní uloží. Pokud je obsah dynamický (tj. jsou uvnitř Latte značky), zpracování pomocí Texy se provádí pokaždé při vykreslování šablony.

Pokud je žádoucí Latte značky uvnitř vypnout, dá se to udělat takto:

{texy syntax: off} ... {/texy}

Do rozšíření lze kromě objektu Texy předat také vlastní funkci a tak umožnit předávat ze šablony parametry. Kupříkladu chceme mít možnost předávat parametry locale a heading:

$processor = function (string $text, int $heading = 1, string $locale = 'cs'): string {
	$texy = new Texy\Texy;
	$texy->headingModule->top = $heading;
	$texy->typographyModule->locale = $locale;
	return $texy->process($text);
};

$latte = new Latte\Engine;
$latte->addExtension(new Texy\Bridges\Latte\TexyExtension($processor));

Parametry v šabloně předáme takto:

{texy locale: en, heading: 3}
...
{/texy}

Pokud chcete pomocí Texy formátovat text uložený v proměnné, můžete použít filtr:

{$description|texy}

Latte 3: největší skok v dějinách Nette

Prosím o fanfáry, na scénu přichází Latte 3. S kompletně přepsaným kompilátorem. Nová verze představuje největší vývojový skok, jaký kdy v Nette nastal.

Proč vlastně Latte

Latte má překvapivou historii. Původně totiž nebylo myšleno vážně. Mělo dokonce demonstrovat, že žádný šablonovací systém není v PHP potřeba. Bylo pevně spjato s presentery v Nette, kde však nebylo defaultně zapnuté a programátor jej musel aktivovat přes tehdejší ošklivý název CurlyBracketsFilter.

Zvrat přišel až s nápadem, že šablonovací systém by mohl HTML stránce rozumět. Vysvětlím. Pro ostatní šablonovací systémy je text v okolí značek jen šumem bez jakéhokoliv významu. Je jedno, jestli jde o HTML stránku, CSS styl nebo třeba text v Markdownu, šablonovací engine vidí jen shluk bajtů. Latte naopak dokument chápe. Což přináší spoustu zásadních výhod. Od komfortu v podobě vychytávek jako jsou třeba n:attributy, až po ultimátní bezpečnost.

Latte tak ví, jakou použít escapovací funkci (což většina programátorů neví, ale díky Latte to nevadí a nevytvoří bezpečnostní díru Cross-site scripting). Zabrání vypsání řetězce, který by v určitém místě byl nebezpečný. Dokonce dokáže předejít dezinterpretaci mustache závorek frontendovým frameworkem. A bezpečnostní experti nebudou mít co žrát :)

Nečekal bych, že tímto nápadem přeběhne Latte ostatní systémy o 10 let, protože dodneška vím pouze o dvou, co takto fungují. Krom Latte je to ještě Soy od Google. Latte a Soy jsou jediné opravdu bezpečné šablonovací systémy pro web. (Byť teda Soy ze zmíněných vychytávek má pouze to escapování.)

Druhou klíčovou vlastností Latte je, že pro výrazy uvnitř značek (někdy se říká maker) používá jazyk PHP. Tedy syntaxi programátorovi důvěrně známou. Vývojář se tak nemusí učit nový jazyk. Nemusí zkoumat, jak se to či ono v Latte píše. Prostě to napíše tak jak umí. Naopak třeba populární šablonovací systém Twig používá syntaxi Pythonu, kde se i zcela základní konstrukce píší odlišně. Například foreach ($people as $person) se v Pythonu (a tedy i Twigu) píše jako for person in people, což zcela zbytečně nutí mozek přepínat mezi dvěma opačnými konvencemi.

Latte tedy má oproti konkurenci natolik podstatnou přidanou hodnotu, že má smysl investovat úsilí do jeho údržby a vývoje.

Současný kompilátor

Latte a jeho syntax vznikla před 14 lety (rok 2008), současný kompilátor o tři roky později. Uměl už tehdy vše podstatné, co se dodnes používá, tedy i bloky, dědičnost, snippety atd.

Kompilátor fungoval jako jednoprůchodový, což znamená, že parsoval šablonu a rovnou ji přetvářel do PHP kódu, který sestavil do výsledného souboru. Jazyk PHP používaný ve značkách (tj. v makrech) se tokenizoval a poté procházel několika procesy, které tokeny upravovaly. Jeden proces doplňoval řetězcové uvozovky kolem identifikátorů, jiný přidával syntaktické vychytávky, které PHP tehdy neznalo (například zápis polí pomocí [] místo array(), nullsafe operátory ?->) nebo které nezná doposud (zkrácený ternární operátor, filtry ($var|upper|truncate), atd).

Tyto procesy ale nijak nekontrolovaly PHP syntax nebo používané konstrukce. Což se výrazně změnilo až před dvěma lety (rok 2020) s příchodem sandbox režimu. Sandbox hledá v tokenech možné volání funkcí a metod a upravuje je, což není vůbec jednoduché. Přičemž případné selhání je vlastně bezpečností chybou.

Nový kompilátor

Za jedenáct let vývoje Latte se našly situace, kdy jednoprůchodový kompilátor nestačil (třeba při inkludování bloku, který ještě nebyl definován). Všechny issue šlo sice vyřešit, ale ideální by bylo přejít na dvoukrokovou kompilaci, tedy nejprve šablonu naparsovat do mezipodoby, do AST stromu, a pak teprve z něj vygenerovat kód třídy.

Taktéž s postupným vylepšováním PHPlike jazyka používaného ve značkách přestávala dostačovat reprezentace v tokenech a ideální by bylo i jej naparsovat do AST stromu. Naprogramovat sandbox nad AST stromem je výrazně snadnější a dá se garantovat, že bude skutečně neprůstřelný.

Trvalo mi pět let se do přepsání kompilátoru pustit, protože jsem věděl, že to bude extrémně náročné. Už samotná tokenizace šablony představuje výzvu, neboť musí běžet paralelně s parsováním. Parser totiž musí mít možnost ovlivňovat tokenizaci, když například narazí na atribut n:syntax=off.

Podporu pro paralelní běh dvou kódů přináší až Fibers v PHP 8.1, nicméně Latte je zatím nevyužívá, aby mohlo fungovat na PHP 8.0. Místo toho používá obdobné coroutines (v dokumentaci PHP o nich nic nenajdete, tak alespoň odkaz na Generator RFC). Pod kapotou Latte se tedy odehrávají kouzla.

Nicméně jako ještě mnohem náročnější úkol mi připadalo napsat lexer a parser pro tak komplexní jazyk, jako je dialekt PHP používaný ve značkách. V podstatě to znamenalo vytvořit něco jako nikic/PHP-Parser pro Latte. A zároveň i nutnost formalizovat gramatiku tohoto jazyka.

Dnes můžu říct, že se mi povedlo všechno dokončit. Latte má kompilátor, jaký jsem si dlouhá léta přál. A z toho původního nezbyl ani jediný řádek kódu 🙂

Nejsi ve vleku cargo kultů?

Před mnoha lety jsem si uvědomil, že když v PHP ve funkci používám proměnnou obsahující předdefinovanou tabulku dat, tak při každém volání funkce musí být pole znovu „vytvořené“, což je překvapivě dost pomalé. Příklad:

function isSpecialName(string $name): bool
{
	$specialNames = ['foo' => 1, 'bar' => 1, 'baz' => 1, ...];
	return isset($specialNames[$name]);
}

A přišel jsem na jednoduchý trik, který znovuvytváření zabránil. Stačilo proměnnou definovat jako statickou:

function isSpecialName(string $name): bool
{
	static $specialNames = ['foo' => 1, 'bar' => 1, 'baz' => 1, ...];
	return isset($specialNames[$name]);
}

Zrychlení, pokud pole bylo trošku větší, se pohybovalo v několika řádech (jako třeba klidně 500×).

Takže od té doby jsem u konstantních polí vždy používal static. Je možné, že tento zvyk někdo následoval, a třeba ani netušil, jaký má skutečný důvod. Ale to nevím.

Před pár týdny jsem psal třídu, která nesla v několika properties velké tabulky předdefinovaných dat. Uvědomil jsem si, že to bude zpomalovat vytváření instancí, tedy že operátor new bude pokaždé „vytvářet“ pole, což jak víme je pomalé. Tudíž musím properties změnit na statické, nebo možná ještě lépe použít konstanty.

A tehdy jsem si položil otázku: Hele a nejsi jen ve vleku cargo kultu? Opravdu pořád platí, že bez static je to pomalé?

Těžko říct, PHP prošlo revolučním vývojem a staré pravdy nemusí být platné. Připravil jsem proto testovací vzorek a udělal pár měření. Samozřejmě jsem si potvrdil, že v PHP 5 použití static uvnitř funkce nebo u properties přineslo zrychlení o několik řádů. Ale pozor, v PHP 7.0 už šlo jen o jeden řád. Výborně, projev optimalizací v novém jádře, ale stále je rozdíl podstatný. Nicméně u dalších verzí PHP rozdíl dál klesal a až postupně téměř vymizel.

Dokonce jsem zjistil, že použití static uvnitř funkce v PHP 7.1 a 7.2 běh zpomalovalo. Zhruba 1,5–2×, tedy z pohledu řádů, o kterých se tu celou dobu bavíme, zcela zanedbatelně, ale byl to zajímavý paradox. Od PHP 7.3 rozdíl zmizel zcela.

Zvyklosti jsou dobrá věc, ale je nutné jejich smysl stále validovat.

Zbytečný static v těle funkcí už používat nebudu. Nicméně u oné třídy, která držela velké tabulky předdefinovaných dat v properties, jsem si řekl, že je programátorsky správné konstanty použít. Za chvíli jsem měl refaktoring hotový, ale už jak vznikal jsem naříkal nad tím, jak se kód stává ošklivým. Místo $this->ruleToNonTerminal nebo $this->actionLength se v kódu objevovalo řvoucí $this::RULE_TO_NON_TERMINAL a $this::ACTION_LENGTH a vypadalo to fakt hnusně. Zatuchlý závan ze sedmdesátých let.

Až jsem zaváhal, jestli vůbec chci koukat na tak hnusný kód, a jestli raději nezůstanu u proměnných, případně statických proměnných.

A tehdy mi to došlo: Hele nejsi jen ve vleku cargo kultu?

No jasně že jsem. Proč by měla konstanta řvát? Proč by měla na sebe upozorňovat v kódu, být vyčnívajícím elementem v toku programu? Fakt, že struktura slouží jen ke čtení, není důvod PRO ZASEKNUTÝ CAPSLOCK, AGRESIVNÍ TÓN A HORŠÍ ČITELNOST.

TRADICE VELKÝCH PÍSMEN POCHÁZÍ Z JAZYKA C, KDE SE TAKTO OZNAČOVALY MAKROKONSTANTY PREPROCESORU. BYLO UŽITEČNÉ NEPŘEHLÉDNUTELNĚ ODLIŠIT KÓD PRO PARSER OD KÓDU PRO PREPROCESOR. V PHP SE ŽÁDNÉ PREPROCESORY NIKDY NEPOUŽÍVALY, TAKŽE NENÍ ANI DŮVOD psát konstanty velkými písmeny.

Ještě ten večer jsem je všude zrušil. A stále nemohl pochopil, proč mě to nenapadlo už před dvaceti lety. Čím větší blbost, tím tužší má kořínek.

Zapisovat nullable types s otazníkem nebo bez?

Vždycky mi vadila jakákoliv nadbytečnost nebo duplicita v kódu. Už jsem o tom psal před mnoha lety. Při pohledu na tento kód prostě trpím:

interface ContainerAwareInterface
{
    /**
     * Sets the container.
     */
    public function setContainer(ContainerInterface $container = null);
}

Obsahovou zbytečnost komentáře u metody ponechme stranou. A protentokrát i projev nepochopení dependency injection, pokud knihovna potřebuje disponovat takovým rozhraním. O tom, že použití slova Interface v názvu rozhraní je pro změnu projevem nepochopení objektového programování, chystám samostatný článek. Koneckonců jsem si tím sám prošel.

Ale proč proboha uvádět viditelnost public? Vždyť je to pleonasmus. Kdyby to nebylo public, tak to pak není rozhraní, ne? No a ještě někoho napadlo z toho udělat „standard“ ?‍♂️

Uff, omlouvám se za dlouhý úvod, to, kam celou dobu směřuju, je zda psát volitelné nullable typy s otazníkem nebo bez. Tj:

// bez
function setContainer(ContainerInterface $container = null);
// s
function setContainer(?ContainerInterface $container = null);

Osobně jsem se vždycky klonil k první možnosti, protože informace daná otazníkem je redundantní (ano, oba zápisy znamenají z pohledu jazyka totéž). Zároveň se tak zapisoval veškerý kód do příchodu PHP 7.1, tedy verze, která otazník přidala, a musel by být dobrý důvod jej najednou měnit.

S příchodem PHP 8.0 jsem názor změnil a vysvětlím proč. Otazník totiž není volitelný v případě properties. Na tomhle PHP zařve:

class Foo
{
	private Bar $foo = null;
}
// Fatal error: Default value for property of type Bar may not be null.
// Use the nullable type ?Bar to allow null default value

A dále od PHP 8.0 lze používat promoted properties, což umožňuje psát takovýto kód:

class Foo
{
	public function __construct(
		private ?Bar $foo = null,
		string $name = null,
	) {
		// ...
	}
}

Zde je vidět nekonzistence. Pokud je v kódu použito ?Bar (což je nutnost), mělo by o řádek níže následovat ?string. A pokud v některých případech budu psát otazník, měl bych ho psát ve všech.

Zůstává otázka, zda není lepší používat místo otazníku přímo union typ string|null. Pokud bych třeba chtěl zapsat Stringable|string|null, verze s otazníkem možná vůbec není.

Aktualizace: vypadá to, že PHP 8.4 bude zápis s otazníkem přímo vyžadovat.