Názory k článku
V PHP pribudne operátor pipe

Ta trojtečka, jako placeholder, kam se má předat vstup je docela vyčůrané.

V PHP to ani nelze jinak, když pozice "důležitých" (tj. co se bude zpracovávat) vstupních argumentů je zcela náhodná :-D

27. 5. 2025, 14:30 editováno autorem komentáře

Pokud to jsou argumenty bez defaultní hodnoty tak musí být řazeny před ty s defaultní hodnotou. Tři tečky znamenají jen to, že tam může být dáno pole s argumenty, které se rozloží na jeden argument po druhém. O nic náhodného nejde.

Až tak náhodná, že se spletl i tvůrce příkladu a v posledním array_filter mají být ... vepředu, nebo mi něco uniká?

Také se mi to nezdá, nebo to nechápu, jak to funguje.

Nejde ani o placeholder, ani o splat operátor, ani o náhodné umiestnenie.
Troma bodkami sa deklaruje referencia na funkciu, tzv. first-class callable.
Tie bodky sa v tomto kontexte teda dávajú na koniec.

Přečti si to znova, a zapoj hlavu, jo?

umí už php konečně placeholder "..." pro první implicitní parametr funkce

aby se nemuselo psát array_sort($a, (bla)->strlen(bla))
ale jen array_sort($a, ()->strlen(...))

heh ?
a co na to array expand(splat moravsky) operátor

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/co­llections 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á.

Generiky jsou těžká záležitost. A toto alespoň potěší.

PHP je snad jediny jazyk, kde se kluci neboji rezat do ziveho :D
(no v tomto pripade spis.. chobotnice - ktere rostou dalsi a dalsi choboty)

Ve skutečnosti se PHP (pokud požíváte vše - od interface, namespace atp. - blíží překládaným jazykům více, než si myslíte).

Nastesti (snad/zatim) nikoho nenapadlo udelat cphp aby to produkovalo binarni exace (ale zas takova blbost by to nemusela byt a klidne se to muze omezit na staticky linking jen pouzitych funkci).

Niečo takéto myslíte?

https://frankenphp.dev/docs/embed/
https://nativephp.com/

Napadlo a to už před drahně lety. Nebojte.

Dělal jsem na střídačku C# a PHP. A moje zkušenost je, že jsou to prakticky identický jazyky. Dobře, PHP má traity, čímž je lepší jak C#, ale víc mě nenapadá.

(Nutno poznamenat, že mám na jazyky velké nároky, takže pro mě je C# nudný jazyk.)

Ty traits ale na prvni pohled delaji dost gulas.. mas nejaky konkretni use case, kde to pouzivas a kde to dela veci vyhodnejsim? (nebo je vsechno zakladni trida a pak ty kompozice jsou zas ciste namixovane z nich?)

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

Tak se zas drží různé verze vedle sebe.

Slon (nikoli chobotnice) v PhPorcelánu bude kompletní, až bude mít od každého jazyka něco.
Ale commiteři, colabboratoři a contributoři si můžou udělat zářez za ten ocaml a za ten druhý bezejmený jazyk, který tam necroretrofitovali.

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í.