Na navigaci | Klávesové zkratky

Typed properties v PHP 7.4 jsou cool, ale ne jak si myslíte?

Po dvou verzích PHP, které nepřinesly nic moc zajímavého, se blíží verze, pro kterou bude mít opět smysl aktualizovat knihovny. Jde o PHP 7.4 a hlavním tahákem jsou typed properties, které uzavírají mnohaletý posun ke striktně typovanému jazyku, což PHP zvýhodňuje oproti jiným webovým jazykům.

Ve zkratce, tahle novinka vám umožní deklarovat typy přímo u proměnných třídy:

class Config
{
	public string $dsn;
	public ?string $user;
	public ?string $password;
	public bool $debugger = true;
}

Příklad použití najdete i v dokumentaci Nette Schema, které je na ně už dnes připravené.

Je potřeba říct, že pokud jste si navykli používat privátní proměnné a přistupovat k nim přes typehintované metody (což je správně), tak vlastně o žádnou killer feature nejde. Druhotná kontrola typů je zbytečná a vlastně jen zpomaluje kód. Diametrálně jiná situace se týká public/protected proměnných, kde dosud neexistoval žádný způsob, jak mít jejich hodnotu (a dokonce existenci) pod kontrolou. Až dosud.

Což nevyhnutelně povede k otázce:

Je nutné dál psát settery a gettery?

Sice veškerý boilerplate kód nám dnes na kliknutí generují editory, ale určitě vypadá hezky, když tohle:

class Circle
{
	private $radius;

	function setRadius(float $val)
	{
		$this->radius = $val;
	}

	function getRadius(): float
	{
		return $this->radius;
	}
}

nahradíte za:

class Circle
{
	public float $radius;
}

Nehledě na to, že i užití objektu je stručnější $circle->radius = $x vs $circle->setRadius($x).

Problém ale je, že velkou spoustu setterů a getterů nelze jednoduše nahradit. Třeba zrovna v uvedeném příkladu by se hodilo ještě ověřit, že poloměr není záporné číslo:

	function setRadius(float $val)
	{
		if ($val < 0) {
			throw new InvalidArgumentException;
		}
		$this->radius = $val;
	}

A v ten moment už nelze kód zredukovat do veřejné proměnné.

Jindy zase chceme, aby jednou nastavená hodnota byla neměnná, což nelze u public proměnné zajistit.

Nebo vůbec nechceme dávat k dispozici getter, protože nepatří do veřejného API třídy.

Anebo chceme mít setter či getter součástí rozhraní.

Atd, atd.

Zkrátka někdy bude možné použít typované veřejné proměnné místo metod, jindy ne, rozdíl bude dost často otázkou vnitřní implementace třídy a pro uživatele neprůhledný. Což je cesta v nekonzistentnímu API, kdy jednou se používá proměnná, jindy metoda a uživatel v tom nevidí logiku. (Podobně jako třeba metoda PDOStatement::errorInfo() vs. proměnná PDOException::$errorInfo).

Prohlubování nekonzistence ale nechceš. Raději konzistentní setrvání u metod, privátních proměnných a všeho toho boilerplate kódu. A pro privátní proměnné, jak jsem zmiňoval v úvodu, je přínos typehintů sporný. Nebo ne?

V čem je tedy výhoda?

Vlastně je výhod dost, i když v jiných oblastech. Typované proměnné budou užitečné pro kompilátor kvůli optimalizacím, pro práci s reflexí nebo nástroje analyzující kód. Důležité budou v šedé zóně protected proměnných. Umožňují zapsat prostředky jazyka to, co se dosud obcházelo komentářem. A navíc přinášejí do jazyka nový příznak neinicializovaného stavu, jakousi obdobu undefined z JavaScriptu.

Komentáře

  1. lopata #1

    Kombinace, která je nejlepší je statické typování s type inference a kompilací a dynamický runtime pro pohodlný a rychlý vývoj. Takže něco jako Typescript. Jak jsem tak zahlédl, tak tohle je runtime, takže jako dobrý no.

    před 5 lety

Tento článek byl uzavřen. Už není možné k němu přidávat komentáře.


phpFashion © 2004, 2024 David Grudl | o blogu

Ukázky zdrojových kódů smíte používat s uvedením autora a URL tohoto webu bez dalších omezení.