Re: First class callable syntax for instance methods

On Mon, Apr 17, 2023, at 2:52 PM, Zoltán Fekete wrote: >> $a = $obj->getConfig() >> |> array_map($$->getId(), $$) >> That is, using $$ to refer to "the value passed from the previous pipe" and >> "make a closure whose argument is an object that we can then operate on". Both of those >> are "obvious" users of $$, but when combined... it's confusing to me which $$ is >> which, at least. > > Yes, I mixed up stuff. > >> That's one of the reasons I preferred partial function applications to have their own >> separate syntax and RFC, and have pipes work on just closures/callables directly. It neatly >> sidesteps this issue, and leaves $$ free for the "closure that takes an object" syntax. >> So the above would become something like: >> $a = $obj->getConfig() >> |> array_map($$->getId(), ?) >> >> Which is less ambiguous. > > What if it's not an object? Let's say an array of arrays? Or an array > of value objects with public properties, and I don't want to call > ->getId(), instead just ->id? > > ``` > $a = $obj->getConfig() > |> array_map($$["id"], ?) > ``` Another example of where "obvious" is not always obvious. > Personally I would keep the $$ for the pipe. Why: > 1. Hacklang has it that way. > 2. I think a lot of people already associate it with this purpose. > 3. I feel that $$ more has “something previously” or “something same”. > As it would be passed through the pipe I feel it fits more. > 4. Maybe the following example is silly but Hacklang is the *only* language that does it that way. Every other language with a pipe, or that has considered a pipe, uses a callable on the RHS. See the notes in the RFC: https://wiki.php.net/rfc/pipe-operator-v2 Expression on the RHS (using $$ as the insertion operator) is considerably less flexible, and precludes incorporating higher-order functions into the process. (Like those in https://github.com/Crell/fp/tree/master/src) Hack simply got this wrong, IMO, and I would likely vote against an RFC with that approach as broken, as it would make it far harder to add the other functional features that are related to pipes. (PFA, a compose operator, etc.) Which would also free up $$ for some kind of "implied object" syntax, as this thread was originally discussing. :-) --Larry Garfield