Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP 8.5 adds pipe operator

thephp.foundation

Post reply on HN
Print view View original

261–270 of 282 posts

Re: PHP 8.5 adds pipe operator

#261

Post by const_cast »

qwertox wrote: post #45
abrookewood wrote: post #37

I love the pipe operator - one of the things I dig about Elixir though many languages have it. It's so much easier to reason about: $result = $arr |> fn($x) => array_column($x, 'tags') |> fn($x) => array_merge(...$x) |> array_unique(...) |> array_values(...) VS array_values(array_unique(array_merge(...array_column($arr, 'tags'))));

I don't see how this is hard to reason about, assuming this is the resulting code when using variables: $tags = ...array_column($arr, 'tags'); $merged_tags = array_merge($tags); $unique_tags = array_unique($merged_tags); $tag_values = array_values($unique_tags); It also makes it easier to inspect the values after each step.

The main problem with this approach, as someone who programs in PHP daily, is it pollutes the scope. That makes debugging much, much harder - you lose track of variables, and the current state of the program is complicated. IMO, if a value is a throwaway, like an intermediate, we shouldn't be able to use it. So method chaining or nesting function calls prevents them. Then, when we break after these functions, we can't see fake values. It also prevents someone in the future mutating the throwaway values. Someone could easily insert logic or a call that mutates something in the middle of this and breaks the chain.

One way this is prevented in PHP is just using functions. But then you have functions just for the sake of scope, which isn't really what they're for. That introduces other annoyances.

Re: PHP 8.5 adds pipe operator

#262

Post by pkkm »

lordofgibbons wrote: post #17

Why doesn't PHP remove the horrid $ symbol for variables and the -> symbol for calling methods? I think those alone would do a lot more for its perception and adoption than adding the pipe operator.

PHP has its significant flaws, but superficial syntactic differences aren't among them. In my experience, it takes two weeks to get used to pretty much any syntax.

Re: PHP 8.5 adds pipe operator

#263

Post by girvo »

r34 wrote: post #60
girvo wrote: post #50

Earlier quoted context omitted.

> so they are more memory efficient They can be. It depends on the language, interpreter, compiler, and whether you do anything with those intermediate variables and the optimiser can get rid of them.

I thought we are talking about PHP8.5:)

Ah, I thought we were talking more generally about PL constructs that let you avoid intermediate variables, apologies :)

Re: PHP 8.5 adds pipe operator

#264

Post by donatj »

hombre_fatal wrote: post #219
donatj wrote: post #142

I had this argument in the PHP community when the feature was being discussed, but I think the syntax is much more complicated to read , requiring backtracking to understand. It might be easier to write. Imagine you're just scanning code you're unfamiliar with trying to identify the symbols. Make sense of inputs and outputs, and you come to something as follows. $result = $arr |> fn($x) => array_column($x, 'values')…

The problem with intermediate assignment is that they pollute your scope. You might have $values and then you transform it into $b, $values2, $foo, $whatever, and your code has to be eternally vigilant that it never accidentally refers to $values or any of the intermediate variables ever again since they only existed in service to produce some downstream result. Sometimes this is slightly better in languages that let…

If PHP scoped to blocks, it would be less of an issue, you could just wrap your procedural code in curly braces and call it a day

    {
        $foo = 'bar'; // only defined in this block
    }
I use this reasonably often in Go, I wish it were a thing in PHP. PHP allows blocks like this but they seem to be noops best I can tell.

Re: PHP 8.5 adds pipe operator

#265

Post by jedwards1211 »

tracker1 wrote: post #234
hajile wrote: post #221

Earlier quoted context omitted.

Closures won over OOP in Javascript a long time ago (eg, React switching from classes to functions + closures), but they still keep trying to force garbage like private variables on the community. Loads of features have been added to JS that have worse performance or theoretically enable worse performance, but that never stopped them before. Some concrete (not-exhaustive) examples: * Private variables are generally 3…

I wish I could upvote this more than once. I really liked the F# inspired pipe operator proposal and even used it a bit when I used to lean on 6to4/babel more, but it just sat and languished forever it seems. I can't really think of any other language feature I've seen since that I would have wanted more. The new Temporal being one exception.

I think it’s mainly because they struggled to get consensus on which syntax to go with for pipelines, since people were divided into three different camps. I wish they would just standardize all three options with a slightly different operator for each one

Re: PHP 8.5 adds pipe operator

#266

Post by tayo42 »

jillesvangurp wrote: post #92
tayo42 wrote: post #14

Earlier quoted context omitted.

I feel like a kindergartener writing go. I wish another language got popular in the space go is used for.

Kotlin is shaping up slowly. It's kind of there with a native compiler that is getting better with each release and decent multiplatform libraries. It's a bit weak with support for native libraries and posix stuff. But that's a fixable issue; it just needs more people working on that. For example ktor (one of the server frameworks) can actually work with Kotlin native but it's not that well supported. This is not usi…

thats interesting, ill have to keep an eye on that.

kotlin always in my mind was android and jvm so i never paid attention to it

Re: PHP 8.5 adds pipe operator

#267

Post by cess11 »

stefanfisk wrote: post #178
cess11 wrote: post #150

Earlier quoted context omitted.

Could you give a realistic example? The PHP pipes as described in the articles about it will require a bunch of wrapping anyway so you could just do that. There are several alternatives, from a function or method that just converts from raw array to class, to abstractions involving stuff like __invoke, __call, dispatchers and such. Also the expectation to not have to put facades on libraries is a bit suspicious, in m…

If I use Laravel’s Str in an app where both myself and a third party library want to add a chainable method, how do I make the API make sense? We can’t both subclass Str. The only option I see is Macroable and that’s a rabbit hole I’d rather avoid.

The Laravel developers expect you to use Stringable::macro if you want to extend their 'fluent' API, and if you're working in an organisation that builds with the Laravel toolchain that's probably what's least surprising to the other members.

I'm still not clear over what you want to do or why the third party library expects there to be a hacked in 'fluent' method on the Stringable.

Personally I'm not a fan of the Str/Stringable API:s, I find it weird and confusing to mix methods for file paths, strings, encryption and so on. Actually, I'm more of a Symfony person for reasons like this.

Re: PHP 8.5 adds pipe operator

#268

Post by tome »

instig007 wrote: post #258
epolanski wrote: post #199

Earlier quoted context omitted.

And yet, while PHPs, Javas, and even nicher/newer languages like Kotlin, Clojure or Scala have plenty of killer software (software that makes it worth learning a language just to use that library/framework) Haskell has none after 30 years. Zero. Mind you, I know and like Haskell, but its issues are highly tied to the failure of the simple haskell initiative (also the dreadful state of its tooling).

> also the dreadful state of its tooling this is plain and unsubstantiated FUD > Haskell has none after 30 years > I know Haskell I doubt it

FYI instig007 is not part of the Haskell community but seems to occasionally lambast people about Haskell, risking giving the Haskell community a bad name: https://news.ycombinator.com/item?id=44199980

Re: PHP 8.5 adds pipe operator

#269

Post by hu3 »

Mystery-Machine wrote: post #188

PHP: $result = $arr |> fn($x) => array_column($x, 'tags') // Gets an array of arrays |> fn($x) => array_merge(...$x) // Flatten into one big array |> array_unique(...) // Remove duplicates |> array_values(...) // Reindex the array. ; // Ruby: result = arr.uniq.flatten.map(&:tags) I understand this is not pipe operator, but just look at that character difference across these two languages. // This comment was my $0.02…

People use Laravel Collections or similar Symfony array wrapper to achieve chaining.

Most PHP code I see look like your Ruby example.

Re: PHP 8.5 adds pipe operator

#270

Post by scotty79 »

xorcist wrote: post #129

"Essentially the same thing" as a shell pipe, except each function run sequentially in full, keeping output in a variable. So nothing like a shell pipe. For short constructions '$out = sort(fn($in)' is really easier to read. For longer you can break them up in multiple lines. $_ = fn_a($in) $_ = fb_b($_) $out = fn_c($_) Is it really "cognitive overhead" to have the temporary variable explicit? Being explicit can be a…

I though so too, but if you are using same name for various things then the whole thing can't be typechecked. Not in PHP at least. In Rust this would work perfectly with typechecking.
Post reply on HN