2023-07-18 20:08 GMT+02:00, Larry Garfield <la...@garfieldtech.com>: > On Tue, Jul 18, 2023, at 5:08 PM, Karoly Negyesi wrote: >> My favorite pipeline is Elixir, where "The pipe operator |> passes the >> result of an expression as the first parameter of another expression".. >> But >> it works there because unlike with PHP, it's almost always the first >> argument you want. If it's not the first argument you needed to do some >> tricks which was only cleaned up in 2021 so now they do: >> >> 5 >> |> then(&Enum.take(1..10, &1)) >> |> Enum.reverse() >> >> but I digress. >> >> My problem here is... we actually need something that passes the RFC >> vote. >> >> What flexibility is missing here? > > Please don't top post. > > The main flexibility for callables is the ability to build a closure on the > fly. For example, using $$ (which Hack does, and I insist on calling > T_BLING) means that for array and string functions you still need to worry > about parameter order. With a callable, you can effectively emulate > Elixir's behavior if you want. > > For example, my FP library has a whole bunch of higher order functions that > just return pipe-ready functions: > > https://github.com/Crell/fp/blob/master/src/array.php > > Which, with a pipe operator, would allow for: > > $result = $arr > |> amap(trim(...)) > |> afilter(is_int(...)) > |> reduce(0, $fn) > |> trim(...) // At this point it's a string and trim() is already unary, > so we can just use it. > ; > > Which is pretty nice, IMO. It "flows" nicely, supports both higher order > functions and direct calls equally well, and allows for all kinds of further > expansion that I haven't thought of yet. > > The Hack style would require thinking about the fact that array_map() and > array_filter() take their arguments in reverse order from each other, which > is just silly. This way, that problem goes away entirely. > > It also allows a pipe to be used as a quasi alternative to scalar methods, > because (if we set aside visibility for the moment) a method is just a > function with an implicit $this parameter. Callables and higher order > functions make that a lot cleaner. > > The caveat is that it does add an extra step to use many of the existing > array or string stdlib functions. However, that's work that can be done > once. The link above is under 500 lines, heavily documented, and covers > every array use case I've run into so far. > > Related improvements: > > * Writing a higher order function right now is rather cumbersome. There > were two previous RFCs that would have made that vastly nicer > (short-functions and auto-capture closures), but neither passed. They would > have allowed for: > > function amap(callable $c) => fn (iterable $it): array { > if (is_array($it)) { > return array_map($c, $it); > } > $result = []; > foreach ($it as $k => $v) { > $result[$k] = $c($v); > } > return $result; > }; > > Which I think is pretty nice. > > * PFA would give us the best of both worlds, as if you wanted you could do: > > $result = $arr > |> array_map(trim(...), ?) > |> array_filter(?, is_int(...)) > |> array_reduce(?, $fn, 0) > |> trim(...) > ;
Damn, that PFA RFC would _really_ help with removing noise, instead of wrapping with fn ($x) => ... everywhere. Shame it didn't pass. :/ 29 vs 20 votes. Olle -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
