RFC – upravit matoucí syntaxi public property služby v services.neon

Jaký je důvod, aby config nezavolal setter?

Property budou čím dál častější. https://wiki.php.net/…operty-hooks

@KamilValenta

Jaký je důvod, aby config cpal cokoliv neznámého do public property?

Nemám na mysli zápis do public property služby, ale „použití public property služby“ pro zápis její hodnoty někam jinam – do konstruktoru jiné služby, nebo jako hodnotu do jiné konfigurační položky. Takže upřesňuji návrh:

Tento matoucí zápis:

session:
	cookiePath: @configProvider::$cookiePath()  #  ?? public method cookiePath() ??

nahradit srozumitelným:

session:
	cookiePath: @configProvider::$cookiePath   #  clear - public property $cookiePath

Pro předání hodnoty do public property služby je v konfiguraci sekce setup:

https://doc.nette.org/…ion/services#…

Ukázka použití public property v sekci setup:

services:
    foo:
        create: \Foo
        setup:
            - $value = 123	# tato syntaxe je správně !!

Syntaxe pro public property v sekci setup je správně – bez závorek. O to víc důvod udělat v tom pořádek a syntaxi public properties sjednotit !!

Můj názor je, že tohle nikdo chtít nemá a tím vlastně padá diskuze jak toho docílit :)

Snad jsem to doplňujícím výkladem dostatečně vysvětlil, že se jedná o běžně používaný postup

@KamilValenta

Z mého pohledu je to paranoidní potřeba vyhnout se setteru, aby se novým, atypickým jazykovým konstruktem napsalo něco jako setter. Vyzdvihovaná ergonomičnost se mi zdá subjektivní, resp. já ji v tom nespatřuji.

RFC jsem si se zájmem prostudoval a není to žádná křečovitá snaha doplnit do PHP něco jenom proto, že to má většina zavedených hlavních programovacích jazyků. Hlavním smyslem property hooks není dublovat settery, tam, kde jsou settery oprávněné se budou dál používat.

Property hooks mají primárně vyřešit problém průběžného doplnění validace do public properties bez změny public API. Přidání validace se provede náhradou public property za private property + setter/getter. To je ale změna public API čili problém. Proto je v PHP zavedenou praxí dopředu předpokládat, že by se toto u každé veřejné public property mohlo stát a jednoduše je nepoužívat a místo nich použít private property + dvojici prázdných setter/getter které se možná využijou, možná ne. Tedy boilerplate kód.

Přidat do public property validaci beze změny public API lze pomocí __set()/__get() což je komplikované a má řadu známých nevýhod.

Property hooks tak de facto nepřináší nějakou zásadní novou feature – můžeš dál používat setter/getter místo property hooks. Přínos property hooks je ve výrazném zjednodušení kódu. Když se člověk podívá okolo sebe, tak všechny významné jazyky (včetně PHP) směřují ke zjednodušení syntaxe – i Java, která je tradičně verbose (ukecaná).

Editoval m.brecher (4. 11. 1:26)

Jak se bude chovat v dědičnosti zatím patrně není známo (?)

Property hooks už jsou dávno mergnuté a stable release PHP 8.4 bude za 17 dní (tj. 21.11.), můžeš si to otestovat. A jak se to chová je sepsané v RFC k nim, nadpis Inheritance.

Předpokládám, že to je jen osobní odhad. Který se (možná) naplní.

Já tím kupříkladu nahradím všechny gettery pro private properties, protože hooks umožňují private set/public get a zjednoduší se tak kód. Společně s tím ale nahradím i ojedinělé settery pro private properties i s jejich validací, což je případ který se řeší tady.

Editoval Marek Bartoš (4. 11. 11:27)

Ahoj,

Změna RFC

díky @KamilValenta a @MarekBartoš za podnětné příspěvky do diskuze. Při opakovaném testování jsem s překvapením zjistil, že syntaxe pro public property je implementovaná správně, ale před 3 lety nebyla a proto jsem tehdy v kódu použil tu která tehdy fungovala $myService::$property() ).

Včera mě zmátly tyto věci:

a) @mesour neon plugin napovídá property syntakticky špatně: @myservice::$property
b) v dokumentaci Nette v odstavci ‘Výrazové prostředky’ https://doc.nette.org/…ion/services#… je uvedena syntaxe pro konstanty, ale aktuálně platná syntaxe property tam chybí
c) syntaxe konstanty a property se liší prvním písmenem – uppercase = konstanta, lowercase = property, což je OK, ale když jsem testoval, tak jsem omylem použil pro property uppercase a nahlásilo mě to, že konstanta neexistuje

Takže není potřeba nic nového v konfiguraci implementovat, stačí doplnit chybějící informace do dokumentace + opravit nesprávnou nápovědu v neon pluginu.

PR do dokumentace: https://github.com/…cs/pull/1065

Editoval m.brecher (4. 11. 23:08)

@KamilValenta

Vzhledem k tomu, že Nette opustilo uppercase pro konstanty

Nette nahrazuje konstanty ve tvaru DEFAULT_VALUE konstantami ve tvaru DefaultValue, kde první písmeno je uppercase takže konfigurace je v souladu s doporučenou praxí pro názvy konstant. Dolar je vyhrazen pro static property. Použití property/konstant v konfiguraci neon je ale ještě složitější než jsem včera psal, protože jsou zde ještě statické property tříd/objektů a objevil jsem v konfiguraci jiné chyby a chyby v pluginu pro neon.

Udělám tedy důkladné testy a pak podám issue pro opravu chyb v konfiguraci i neon pluginu.

Editoval m.brecher (7. 11. 2:18)