Vlákno názorů k článku
Nové PHP 8.4.1: háčky vlastností, nesymetrická viditelnost a líné objekty od Humanoid č. 1264054 - poruchový - Já se s dovolením domnívám, že se PHP...

Já se s dovolením domnívám, že se PHP vyvíjí trochu směrem "Jak pejsek s kočičkou dělali dort". Třeba kombinace constructor promotion (https://wiki.php.net/rfc/constructor_promotion) a nového property hooks (https://wiki.php.net/rfc/property-hooks) vytváří nepěkný a nepřehledný kód. A to, co je opravdu důležité, generiky, pořád nikde...

Na nějaký přednášce někdo, kdo se podílí na PHPStanu, mluvil o tom, že nativní generika v PHP nejsou jednoduchou záležitostí a v blízké době se jich nedočkáme, protože by to vyžadovalo velké interní změny. Nicméně PHPStan funguje hodně dobře, takže mě to moc netrápí, štve mě to ideologicky, ale funkčně je to v pohodě.

Co se týče promoted properties, ty mi přijdou super. Kotlin to má podle mě daleko nepřehlednější. Chápu myšlenku za tim a nedokážu se rozhodnout, jestli mě to vyloženě štve, nebo jen mrzí, že nepřišli s něčim elegantnějšim.

property promotion naopak kod zprehlednuje, je to jednoduchy a cisty reseni. pomoci rectoru jsme to automaticky nahradili nad celou codebase a nikdo z tymu nerekl jedine slovo proti (naopak).

Tak jsem si vygooglil ten property promotion a je to takový syntaktický cukr, že bych dostal cukrovku. Připomíná mi to, jak v PHP a Pythonu můžu přiřadit hodnotu do proměnné objektu, která není deklarovaná v třídě toho objektu. I když aspoň ten property promotion je jasně definován, takže doplňování kódu si s tím poradí...

25. 11. 2024, 13:16 editováno autorem komentáře

jak jsi napsal v posledni vete: ono to tam je, IDE to chape.

Rozhodně bych to považoval za lepší řešení než status quo, který dává několik možností:

a. Vždy psát gettery a/nebo settery.
b. Změna na getter je BC break.
c. Udělat si property hooky přes __get/__set.

Otázka ještě je, jestli půjde definovat properties pro interface. Pokud ano, bral bych to jako to nejčistší řešení, se kterým PHP přišlo.

Ano, jedna z novinek z tohoto plynoucí je ta, že nyní jde mít definici property v interface

Jo, ale když je to zapravené v argumentech konstruktoru, přičemž jiné property jsou ale nad ním, tak to tak přehledně nepůsobí.

S tim souhlasim, ale v PHP aspoň máme možnost volby. U DTO všechny proprty mužou bejt promoted, u aggregátů zas naopak budu potřebovat neveřejné proprty, takže pak promoted nepoužiju vůbec. Například v takovym kotlinu se to sice dá udělat stejně, ale pokud nebudete chtít jít proti proudu a upravit si pravidla výchozího formátovacího lintu, tak vám toho kočkopsa dělat bude.