Podle mého názoru úplná zbytečnost. Dělám v PHP hodně a na podobné věci používám fluentní rozhraní některého z frameworků. A nevidím důvod to dělat takto opačně. Podobně je to třeba i v Rustu.
PHP se vůbec poslední dobou zabývá nepodstatným a stále nejsou generiky... a nebudou...
Priznam se, ze nerad pouzivam takovyhpe veci, napriklad kolekce, z frameworku, pokud to neni samostatny balicek. Osobne na kolekce (na soukromych projektech, v praci dodrzuju to, na cem jsme se dohodli) mam vlastni, predtim jsem pouzival cizi balicky. Teoretickej problem vymeny frameworlu jsem uz zazil, resp nezazil, protoze kuli pouzivani kazdy kraviny z frameworku v domene to znamenalo vlastne prepsani cele aplikace.
V princípe súhlas - framework agnostic prístup ale v praxi či funguje reálne by som skôr povedal, že nie. Konkrétne Collection z Laravel má toho toľko využiteľného, že neviem čím by som to nahradil. Vymeniť celý framework (napr. Laravel za Symfony) by projekt zabilo, lebo to nikto na podobný case nepripravil a nepoužiť Collection by vlastne nič nezachránilo.
Písať si vlastne implementácie na podobné veci - nie je na to čas, ani ľudia, klient to nezaplatí. Výmenu frameworku na projekte za behu (t.j. že sa to neprepísalo komplet na zelenej lúke, ale postupne sa to refaktorovalo do stavu, že sa dal framework vymeniť) som za 16 rokov ešte nemal tú česť a asi ani na jednom projekte, ktorým som prešilo by to reálne nešlo (cca 10 rôznych projektov s rádovo stovkami tabuliek) - nikto to na začiatku nepredpokladl a celé to bolo silno previazané s frameworkom.
Komplet nový projekt, kde by sa na podobný prípad myslelo si viem predstaviť, že by sa to prepojenie s frameworkom dalo minimalizovať a jeho výmena by bola reálna.
Sice jsem psal framework, ale pochopitelně je dneska dobrým mravem jednotlivé části frameworku balíčkovat a umožnit jejich použití nezávisle na frameworku. Pro zmíněné illuminate/collections to není problém a mám to tak u mnoha projektů, kde je potřeba víc kouzlit s kolekcema a už se vyplatí to takhle udělat. A upřímně řečeno, ono se to "shodou náhod" vyplatí skoro vždy;-)
Samozřejmě, že měnit framework jako celek je už velký zásah, protože nejde jen o nějaký soubor nástrojů, ale o komplexní produkt, pro který je aplikace napsaná.
Traity jsou reusable kódu udělané správně.
Třeba takové C++ na reusable používá dědičnost, protože nic jiného nemá. Což ale zpětně vyvolává dojem, že je to správně, což, jak víme, není.
C# má alespoň rozhraní. Ale nemá traity. Takže když potřebuješ reusable kódu co uděláš?
1/ injektáš - jenže ty ne vždy chceš umožnit měnit implementaci. Navíc to vytváří příliš velkou volnost, což ne vždy je žádoucí.
2/ vytvoříš inplace instanci - jenže to znamená, že ta třída musí být veřejná (v C# nemusí, v PHP musí)
3/ dědičnost - výhoda je ve vhodném těsném vztahu. Nevýhoda, že skáčeš jak blbec skrz pět úrovní dědičnost. Hlavně to ale vytváří nežádoucí vztah "is".
V C# je, asi, nejvhodnější vytvoření privátní třídy, čímž simuluješ reusable. Problém vidím v tom, že děláš něco jiného, než co potřebuješ. V PHP napíšu traitu, a tam narvu všechno co potřebuju sdílet napříč třídami. Jasně a srozumitelně tím deklaruju o co mi jde. Vulgárně řečeno děláš dědičnost bez dědičnostil = to chceme.
Pak je samozřejmě už jen na mé soudnosti, jak moc to rozfrcám. Zneužít se dá všechno.
28. 5. 2025, 17:56 editováno autorem komentáře
A nejaky konkretni priklad na cos to pouzil ?
(me nejde do hlavy tohle - bud tam jsou ortogonalni featury - a na to pak staci nejaky struct/wrapper, anebo featury nejsou ortogonalni, ale pak si jako nejaky trait saha do properties ktere ani nema definovane?)
28. 5. 2025, 17:59 editováno autorem komentáře
Vytvářel jsem skupinu grafických tříd: Scalar, Record, Collection, ... Každá měla specifické chování, ale každá z nich měla metody/prvky name, label, description, help, ... a další. Vytvořil jsem si traity jako ControlBaseUnit, ControlRulesUnit, ControlTransformationUnit.
Ve vlastní třídě tam pak zůstalo jen to, co nebylo společné.
28. 5. 2025, 18:08 editováno autorem komentáře
Obhájit se musí vždycky všechno. To je tak nějak normální.
Že by "Většinou zjistím, že se daný problém dá řešit elegantněji a úsporněji." se mi nechce moc věřit.
To spíš, že programátor ze samého nadšení "jů traity", je používá nesmyslně. Což je, opět, normální.
Naštěstí přehnané použití traitů není tak škodlivé, jako dědičnost.
Jo, ocaml v phpku chybělo . ještě něcoz z LISPu a Prologu by to chtěl připéct.
Ukázka "Tradičný" je nekompletní, chybí tam druhý array_filter, aby vyniklo a(b(c(...)))) hell. Neplést se spagheti kódem, tohle je závorková matrjoška.
Ale tady přestává veškerá sranda. Proč se do phpích kulí nepoužije objektový funkcionální kód
$numbers . array_map (_){ _.toString(8)} ).map(&.reverse) .array_sort( ()->(_[0]) ).array_filter( (bool)) #jde o brainstorming
? Ano, rozdíl mezi . / -> (metoda objektu) a |> (pipe textového streamu)je fundamentální, proč už to tam dávno není.