Vlákno názorů k článku
Nové PHP 8.4.1: háčky vlastností, nesymetrická viditelnost a líné objekty
od Ink - Zdá se mi to, nebo tvůrci PHP soutěží...
-
Prečo? Mne príde PHP čím ďalej tým lepším jazykom. V podstate všetky novosti sú prevzaté s miernymi úpravami z iných jazykov. Property hooks sú automatické properties zo C#.
Ak budú schválené niektoré z nasledujúcich RFC, bude PHP jedným z top jazykov. Napr. records, data classes, kompozícia funkcií ala F#, list comprehensions, algebraické dátové typy...
23. 11. 2024, 19:14 editováno autorem komentáře
-
Tak pouzivat to nemusite ale muzete (napriklad type hinting, striktni private/protected/public, atd.). Vzdy tam zustava jednoduchy zaklad a to na nejake rychlo bastly je vyborny.
Pro slozitejsi projekty, kde jde vice o cistotu kodu a ohlidani se pred "uzivatelem" (programatorem, ktery vyuziva muj kod/knihovnu) je to pak lepsi doplnit prave prave o ty vylepseni.
Jediny co me prijde divny je, ze se syntaxe rozviji v minor verzich.. byl bych radeji kdyby pouze major verze prinasela novinky v syntaxi, pak je snazsi ohlidat kompatibilitu prostredi. Minor at resi vykonnostni / interni veci, a treti uroven hotfixy na bugy.
-
Tak já jsem třeba v C# a v Javě dělal. Že by to byl nějaký zvláštní zázrak, to se říct nedá. Jako když mi za to někdo zaplatí, tak jsem ochoten v tom něco dělat. Ale že bych do toho šel dobrovolně... Nestojí za námahu.
PHP, C# ani Java nejsou jazyky, které bych použil na projektu protože bych chtěl.
-
Podobné veci počúvam o C++ minimálne od roku 2011. Napriek tomu, prekvapujúco, počet programátorov v C++ neustále stúpa a stúpa určite aj kvalita kódu, ktorý vzniká. Človeku, ktorý sa o programovanie trochu zaujíma a má prehľad aj o iných prístupoch k programovaniu ako ten najbežnejší, musí byť jasné, že prácu si chce zjednodušiť každý a ak sa nejaký koncept osvedčil v jednom jazyku, stojí za to preniesť ho do iného, zvlášť do takého, ktorý je z nejakého dôvodu populárny.
-
To souhlasim - viz treba lambda funkce. (od PHP 7.1).
Problem je spis ze se ten jazyk - jako tyhle featury a syntaxe meni jako v malem poctu. Kazdy zna rozdil mezi C a C++, ale uz mene lidi vi co je v ruznych revizich C++ (98,03,11,14,17,20,23,26).
Podobne to mam u PHP - pouzivam to v kombinaci s bashem jako primarni skriptovaci jazyk (cca 300K+ LoC vlastnich/internich knihoven, udelatek, toolu atd), ale nejak jedu porad copy paste struktury ktere znam z pred 10 let - a to verim ze od te doby se to dost posunulo. Problem je, ze kvuli jednomu malemu zlepseni se tezko meni navyky (napr. vim ze konstruktor lze napsat chytre, aby inicializoval/definoval nektere properties.. nicmene to nepouzivam - jednak nemam zazitou onu syntaxi, a pak druhak prijde mi jasnejsi kdyz jsou veci definovane explicitne, oldschool.. nez nejakym ohybakem).
-
Tak nemusíte to používat všude. Ale třeba u jednoduchých DTO to podle mě je daleko přehlednější, než mít samostatně definovaný proprty a konstruktor s parametrama a jejich setování do proprt
<?php
class readonly CreateUserCommand {
public function __construct(
public UserId $id,
public Email $email,
public PasswordHash $passwordHash,
) {}
}Nezjistil jsem jak udělat, aby to neodstranilo odsazení.
25. 11. 2024, 09:17 editováno autorem komentáře
-
Dle napovedy dole by zde mel fungovat PRE tagyna odsazeni, ale vidim co myslite.
Jako u jednoduchych veci co chci nasledne sdilet skrze referenci spis pouzivam (object)Array( x => y ... ), u tech slozitejsich objektu pak je vicero statickych metod kterymi lze objekt vytvorit, takze tam je zas typicky v tech metodach $obj=new Self() a return false/null pro chybu nebo nemoznost vytvoreni (Exception pouzivam spis jen pro fatalni chyby, protoze to ma hezky backtrace, ktery napovi proc se to cele rozbilo, nez abych to zas maskoval pres try/catch). Takze vlastne klasicke new Class(...) s parametry zas ani nepouzivam mi prijde.
-
Asociativní pole považuju za zhůvěřilost v drtivý většině případů, aspoň teda na dlouho žijícim projektu. Na něčem, co si splácám za víkend doma, asi ok.
Dá se sice anotovat tak, že to nahradí dto, jenže pak musíte tu anotaci psát všude, kde jde to asociativní pole (nebo aspoň ty klíče, který pak nadále chcete používat). Ve výsledku mi přijde jednodušší a přehlednější si vytvořit DTO jako v jakymkoli jinym jazyce.
-
Pretypovani asociativniho pole na objekt je prave vyhodou skriptovaciho jazyka typu PHP, ze muzete velice rychle naprototypovat neco, cim by jste stravili mnoho casu nekonecnym refakoringem trid ve vasem klasickem jazyku.
Proto prece to PHP pouzivam, abych mohl delat tyhle "nestandardni" veci a nemusel se drzet striktni struktury vynucovane z duvodu kompileru a linkeru u klasickych jazyku. Netypovost promennych je dalsi takova vyhoda - kdyz proste delate neco a neni jasne jak to dopadne, nebo potrebujete protlacit nejaky OOB meta info. Ostatne takove "praseni" skrze negativni hodnoty cisel pouzivane jako chybove kody mate i v klasickych jazycich, neprasi se jenom v PHP :)
-
Já teda netypovost za výhodu nepovažuji, spíš naopak.
A pak máte seriózní víceletej projekt, kterej je psanej v PHP, a nechcete, aby se vám děly věci jako že otevřete službu, která přijímá asoc pole, to tam jde z kontroleru, kde se jen deserializuje payload a neni nikde definovaný schema, takže nemáte absolutně páru, jaký data tam teda maj jít.
Já chápu, že když si v tom píšete POC nebo tak něco, nemá cenu se s tim nějak víc patlat. Ale ne všechny projekty jsou takové a na těch dlouhodobějších určitě nechci používat asoc pole, místo něj chci používat nějaký DTO. Tady pak ty promoted properties celý DTO podstatně zjednoduší a zpřehlední.
Že se prasí všude je muj argument, proč jedna ošklivá zkušenost v PHP ještě nedělá automaticky z PHP špatnej jazyk, nebo z jeho programátorů podřadnou formu života. Ale to přece neznamená, že když se prasí jinde, budu prasit taky. Jasně, nezavedu hned DDD, nebo aspoň baznys/infrastukturní vrstvu na miniprojekt, Každopádně považuji za fakt, že prasení z dlouhodobýho hlediska jen snižuje výkonnost a podstatně zvyšuje chybovost.
