Názory k článku
Nové PHP 8.4.1: háčky vlastností, nesymetrická viditelnost a líné objekty
-
Naopak, texty majú byť zrozumiteľné, zvlášť keď sú informačné. Slová majú svoj význam a význam, v ktorom sú preložené je ten istý, aký majú v pôvodnom jazyku. Väčšinou sa odkazujú na obory mimo IT a slová ako fixture, boilerplate, harness, hook, pool, atď. naozaj existovali a používali sa v nich dávno pred tým, ako nejaké IT vôbec existovalo. A preto boli prevedené do IT, lebo k kontexte IT sú výstižné a popisujú analogické veci ako v pôvodných oboroch a človek, ktorý si to uvedomí má lepšie šance na pochopenie alebo na vysvetlenie danej témy ďalším ľuďom, ktorí ani nemusia byť z IT.
-
Různí lidé mohou mít různé názory, osobně bych raději zůstal u jednotné terminologie v angličtině. Pod háčkem si představím asi něco jiného, než je v tomhle smyslu 'hook', pool bych místo jako bazén spíš překládal jako množina, a když to dovedu ad absurdum, bazén nití laikům moc nepomůže.
Občas si při čtení českých pasáží kolem IT musím text přeložit slovo po slově do angličtiny, a pak mi dojde význam. Ale určitě se najdou termíny, které jsou v češtině/slovenčine zažité. -
Bazén som mal presne na mysli, keď som to písal. Pointa je v tom, že slovo pool sa do vášho a aj do nášho jazyka prekladá aj v inej oblasti ako IT, pričom v tej oblasti sa to slovo používalo dávno pred tým ako nejaké IT vôbec existovalo. Takže patent pool sa v oblasti ochrany duševného vlastníctva prekladá ako patentový fond. Myslím v publikáciách z toho oboru. Teda z oboru, kde nepracujú iba technici, bez ohľadu na to či sú z IT alebo aj mimo IT, ale aj právnici a ekonómovia. A je celkom možné, že aj slovo fond sa používalo dávno pred tým, ako boli nejaké patenty. Thread pool alebo memory pool je koncepčne to isté ako patent pool, iba druh položky je iný. Takže správnym prekladom bazénu nití bude asi fond vlákien. A tomu už niekto, kto nie je z vášho oboru, rozumieť bude a zvlášť tomu bude rozumieť vaša prípadná protistrana, keď sa budete dohadovať s potenciálnym investorom alebo poradcom, ktorému budete vysvetľovať prečo by vám mal dať peniaze, prípadne aj s manažérom, pokiaľ má trochu prehľad.
Jednoducho, slová, ktoré sú používané v IT majú veľmi často svoj pôvod v iných oboroch a v rámci týchto oborov sú už dávno preložené do vášho jazyka a dlhodobo sa používajú.
Pôvod a analógie slov ako fixture alebo aj hook si už určite nájdete sám.
-
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.
-
Humanoid č. 1264054 - poruchovýBronzový podporovatel
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.
-
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
-
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.
-
Díky za doplnění!
Pak mi přijde, že:
1. PHP již dávno nezaručuje, že čtení/zápis property bude jen jednoduché přiřazení (dávno máme __get/__set). Je to jedna z variant – Java jde opačnou cestou, ale za cenu psaní getterů. (Ano, Lombok to v Javě nějak řeší.)
2. Narozdíl od předchozích řešení (__get/__set) to dobře zapadá do jazyka (interfaces) a zároveň to je i celkem jednoduché na použití. (Jednoduchost na použití __get/__set řešilo Nette, v rámci omezených možností asi celkem dobře.) -
Humanoid č. 1264054 - poruchovýBronzový podporovatel
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.
-
Pretože slovo symetrický dávno zdomácnelo. Keď sa spýtate svojej starej mamy, bude vedieť, čo znamená. Keď sa je spýtate, čo je to hook alebo fixture, tak to, nechcem ju naozaj podceňovať, vedieť nebude. No a okrem toho, slová, ktoré majú grécky alebo latinský pôvod, ako má toto slovo, sa často preberajú v pôvodnej forme.
-
Pôvodná otázka sa týkala symetrie, tak som sa na ňu snažil odpovedať. Ostatné je doplnok. Aj v odbornej reči sa používajú preložené výrazy a určite existuje nejaký dôvod, prečo máme pamäť a nie memory, ukazovateľ a nie pointer, cyklus a nie loop, vlákno a nie thread, prúd a nie stream, súbor a nie file, medzipamäť a nie cache, ... So starou mamou čiastočne uznávam, ale to, že nebude vedieť, čo je fixture alebo hook, je v poriadku. Nie je ale v poriadku, keď to nevie veľa ľudí, ktorí tie výrazy používajú, lebo nepoznajú kontext a majú menej záchytných bodov na to, aby si danú tému osvojili napríklad na základe nejakej ľahko predstaviteľnej analógie. Som jednoznačne na strane každého autora, ktorý používa lokálne výrazy, pretože si dal značnú prácu s tým, aby sa mu dalo rozumieť a aby mu rozumeli nie len tí, čo si o sebe myslia, že sú borci, ale aj ľudia, ktorí do oboru alebo témy ešte iba prenikajú.
ČLÁNKY DO MAILU