Změna chování {default} v Latte – sjednocení s ??= operátorem

Pokud explicitne predam do parameteu null cekal bych ze zustane zachovane null. Stejne jako u parametru volani metod.

Dovedl bych si ale predstavit ze by bylo uzitecne mit jednoduchy zapis pro doplneni default null hodnot.

Co treba takhke: {default $var ??= 123}

Měnilo se nějak chování {default} v nové verzi Latte?

Začaly nám totiž padat testy u efabrica/phpstan-latte při analýze šablon s tímto tagem.

Šablona obsahuje:

{default $someVariableWithDefault = 'default value'}

Proměnná $someVariableWithDefault není definovaná (což analyzátor ví).

Dřív to PHPStan vyhodnotil že tak, že typ proměnné je 'default value', ale teď to dává 'default value'|null

Je to záměrná změna chování nebo chyba v analýze?

Vygenerovaný kód v šabloně vypadá teď takto:

$someVariableWithDefault ??= \array_key_exists('someVariableWithDefault', \get_defined_vars()) ? \null : 'default value';

Z toho mi vychází že pokud proměnná není definovaná mělo by se přiřadit 'default value', ale PHPStan možná nedává tu „magii“ s array_key_exists a get_defined_vars.

Editoval mystik (31. 10. 13:26)

Vypadá to na limitaci PHPStanu. buď to zkusíme nějak dořešit v PHPStanu nebo budem dělat nějaký preprocessing

PHP zavedlo null jako plnohodnotny „typ“, tzn. povazovat null hodnotu za „undefined variable“, pro ktery potrebuji default, mi prijde neprakticke a „mirici“ opacnym smerem.

function foo($param = 'default') {
  return $param;
}

foo(); // 'default'
foo(null); // null

Tamto se to chova u defaultu parametru funkce. IMHO by se to melo stejne chovat u defaultu parametru sablony.

@mbrecher Podivej se na to spis takto:

• nullsafe operator je neco jineho nez default hodnota a navic uz jde v latte pouzit
• predstava, ze mi nekdo prepisuje explicitne nastaveny null me desi, ikdyz chapu, ze tu zadna detekce na explicitne nastaveny null nemuze byt;
• default chapu jako vhodny konstrukt, kdyz je sablona pouzita v ruznych flow a nekde proste tu variable nenastavim

Obecne bych nedelal zbytecny bc breaky. Pokud potrebujeme “replacovat” null a chceme to mit jako macro, zavedl bych nove makro. {defaultIfNull $var = 123}

@hrach

predstava, ze mi nekdo prepisuje explicitne nastaveny null me desi

@KamilValenta

A skutečně, pokud někde v argumentu uvedu null, očekávám tam null, ne cokoliv jiného, co je výchozí hodnotou.

Explicitní nastavení hodnoty null, která se nesmí přepsat defaultní hodnotou, zatímco ‚undefined‘ se přepsat musí, signalizuje použití null s jiným významem než ‚undefined‘. Dělá se to běžně, ale vede to k méně čitelnému kódu a vznikají komplikace. Komponenta předá do šablony null s tím, že se null nesmí přepsat defaultní hodnotou. Autor šablony ale používá null stejně jako ‚undefined‘ a místo {default $num = 0} použije {do $num ??= 0}. Autor komponenty nemůže zabránit tomu, aby autor šablony nepřepsal null defaultní hodnotou. I když funkci {default} nebudeme měnit může nastat tato „děsivá“ varianta :).

Jak se „děsivé“ variantě vyhnout? Ideálně tak, že všichni budeme používat null ve významu ‚undefined‘. Jestliže vznikne situace, že přepsání null defaultní hodnotou způsobí problém, použijme místo null jinou hodnotu (0, false) a ponechejme null volné pro možnost explicitní deklarace ‚undefined‘.

Souhlasím ale s @KamilValenta, @mystik, @hrach, že ideální řešení je rozšířit syntaxi {default $var ??= 123}, a nedělat BC breaky, když to není nutné.

Editoval m.brecher (6. 11. 0:37)

m.brecher napsal(a):

vede to k méně čitelnému kódu

To je subjektivní pohled na věc. Mystik uvedl příklad s foo(), který je naopak velmi čitelný a jiné chování by bylo matoucí.

Autor šablony ale používá null stejně jako ‚undefined‘ a místo {default $num = 0} použije {do $num ??= 0}. Autor komponenty nemůže zabránit tomu, aby autor šablony nepřepsal null defaultní hodnotou.

Autor šablony ví proč nerozlišuje (nebo naopak rozlišuje) null od undefined. A autorovi komponenty to může být jedno, ten předal co chtěl a šablona se s tím vypořádá podle svého.
Jedna šablona může být sdílena více komponentami, ne každá komponenta do ní pošle stejné atributy (undefined), ale když už je pošle, mohou být prázdné (null).

Jestliže vznikne situace, že přepsání null defaultní hodnotou způsobí problém, použijme místo null jinou hodnotu (0, false) a ponechejme null volné pro možnost explicitní deklarace ‚undefined‘.

Rozumím tomu dobře, že zavrhuješ používání null ve významu null a undefined ve významu undefined – místo toho chceš používat null a undefined ve významu undefined a 0+false ve významu null? Opravdu Ti to dává smysl?

@mystik

Rozliseni null vs undefined se bezne pouziva v rade jazyku. Proc myslis, ze by se to rozlisovat nemelo?

Null by se mělo používat ve významu ‚hodnota neexistuje‘, což je sice stejný význam jako u neinicializované hodnoty ale null a ‚undefined‘ se podstatně liší tím, zda tento stav znamená chybu nebo ne. Null je vědomé nastavení neexistující hodnoty, které v kódu zpracujeme bez výjimky, zatímco neinicializovaná proměnná znamená chybu, která by se měla v kódu opravit. Všichni to takto běžně používáme.

Jenže v aplikacích se často null ve významu ‚neexistující hodnota‘ nepoužívá. Běžně se návrh databáze příliš zjednodušuje a hodnota null pak něco konkrétního znamená, obvykle nahrazuje jedno boolean pole. Příklad:

Striktní přístup – null ve významu ‚hodnota neexistuje‘

public bool $runProcess;		// true = run process, false = do not run process
public ?DateTime $startAt;		// DateTime = datum spuštění, null = datum neexistuje

Zjednodušený přístup – null se skrytým významem ‚do not run process‘

public ?DateTime $startRunAt;	// DateTime = run process + datum spuštění, null = do not run process + datum neexistuje

Ve druhém případě $startRunAt = null má skrytý význam ‚do not run process‘ zatímco ‚undefined‘ nikoliv. V takovém případě se explicitně nastavené null nesmí přepisovat nějakou defaultní hodnotou – to je případ který Jsi zmínil. V prvním případě to nevadí. A protože bezpochyby je druhý způsob použití null běžný, tak je návrh neměnit {default}, rozumný a každý si použije v aplikaci tu variantu, která mu vyhovuje.

Jinak v souvislosti ve šablonama je ještě důležité je tu ještě jedna pikoška. Pokud si kvůli kontrole a napovídání typů vytvořím třídu:

class TemplateParameters
{
	public string $lang;
}

$params = new TemplateParameters;
//$params->lang = 'cs';
$html = $latte->render('template.latte', $params);

…tak pokud nenastavím $params->lang, bude mi fungovat {default} v šabloně. Ale pozor, pokud by property $lang neměla typ:

class TemplateParameters
{
	public $lang;
}

…tak už by {default} nefungoval, protože netypované proměnné mají vždy výchozí hodnotu null, kterou už pak {default} nepřebije.