On Fri, Apr 14, 2023, at 5:52 AM, Zoltán Fekete wrote: > That sure does it, but not that type safe though.
Right, which is why I'm fully on board with finding a native syntax way of doing it. (It would be faster, to, without two extra user space function calls.) > The T_BLING (that is the only name I will allow for $$) marker has been >> discussed on and off a few times over the years, I think first in Sara's >> original pipes proposal many years ago. I was actually going to suggest >> the same in this thread before I saw you did. :-) >> > > Yes I found it. Actually there were many discussions about it. I didn't > really went through them, but how had it never made through? (I'll take > time to read through ofc) Sara didn't take her version to a vote. About 2 years ago I tried with a reduced scope version (just the pipe operator, working on callables; partial application was a separate RFC), but it didn't pass. I want to try again at some point, if I can get assistance on a better implementation than my paltry skills were able to manage before. (And if we can collectively make a stronger argument for it.) >> More abstractly, $$ meaning "the only obvious value in context" has >> potential, but also risk, because "obvious" is not always obvious. I do >> think it's an area to explore, though, and would definitely help with >> functional style code that relies heavily on closures. > > I'm not sure I understand how this could not be "always obvious". IF, - > let's say we stick to what hacklang has: > https://docs.hhvm.com/hack/expressions-and-operators/pipe - I think it's > farily straightforward > > $a = $obj->getConfig() > |> array_map($foo => $foo->getId(), $$) > |> array_filter($foo => $foo !== "woof", $$) > |> $this->toResponse($bar, $$, $baz); > > But to get back to the original topic: I think this is what you were > looking for. That's actually a perfect example of where obvious isn't obvious. Consider, if you instead did: $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. 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. in my mind, these are all separate language features (PFA, pipes, and lenses) that have their own distinct uses, but they need to be designed in tandem so that they mix well together. Sadly, PHP doesn't do well with that kind of mini-roadmap. :-( --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
