Live data from Hacker News

PHP 8.5 adds pipe operator

thephp.foundation

191–200 of 282 posts

Re: PHP 8.5 adds pipe operator

#191
post #88
post #45

Earlier quoted context omitted.

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.

I don't think inspecting this is easier than adding |> IO.inspect() to a pipe chain

modifying code just to attach a breakpoint is kinda silly in this day and age.

Re: PHP 8.5 adds pipe operator

#192
post #170

The first typed programming language where I've seen pipe operator |> in action was in F#. You can write something like: sum 1 2 |> multiply 3 and it works because |> pushes the output of the left expression as the last parameter into the right-hand function. multiply has to be defined as: let multiply b c = b \* c so that b becomes 3, and c receives the result of sum 1 2 . RHS can also be a lambda too: sum 1 2 |> (f…

Haskell seems pretty dead as well. Good think php has another option for line noise though.

What makes you believe Haskell is dead or even dying? New versions of GHC are coming out, and in my experience, developing Haskell has never been smoother (that’s not to say it is completely smooth).

Re: PHP 8.5 adds pipe operator

#193
post #146

Earlier quoted context omitted.

Your simple example (`2 |> Math.sqrt`) looks great, but when the code gets more complex, then the advantage of the pipe syntax is less obvious. For example, foo(1, bar(2, baz(3)), 3) becomes something like 1 (2, (3 |> baz) > bar), 3 |> foo or (3 |> baz) |> (2, % |> bar) |> (1, %, 3 |> foo) That looks like just another way to write a thing in JavaScript, and it is not easier to read. What is the advantage?

Uhm, don't do it, then. That's like arguing that the addition of the ternary operator is a bad one because not all if/else blocks look better when translated into it. The goal is to linearlize unary function application, not to make all code look better.

I think the commenter meant that once the new syntax is approved and adopted by the community, you have no choice to not use the syntax. You'll eventually change your project and will be forced to deal with reviewing this code.

Re: PHP 8.5 adds pipe operator

#194
This is great! Hat tip to PHP. I first came across pipes in Elixir and have ever since missed it in every other language. Two observations:

- pipes make you realize how much song and dance you do for something quite simple. Nesting, interstitial variables, etc all obscuring what is in effect and very orderly set of operations.

- pipes really do have to be a first class operator of the language. I’ve tried using some pipe-like syntactic sugar in languages without pipes and while it does the job, a lot of elegance and simplicity is lost. It feels like you are using a roundabout thing and thus, in the end, doesn’t really achieve the same level of simplicity. Things can get very deranged if you are using a language in a way it wasn’t designed for and even though I love pipes I’ve seen “fake pipes” make things more complicated in languages without them.

Re: PHP 8.5 adds pipe operator

#195
I used php professionally for a decade and I still don't get why in the year 2025 we need to reinvent syntax that is virtually standard in every language

Re: PHP 8.5 adds pipe operator

#196
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')…

I don't disagree with you. I had trouble reading the examples at first. But what immediately struck me is this syntax is pretty much identical to chaining object methods that return values.

  $result = $obj->query($sqlQuery)->fetchAll()[$key]
so while the syntax is not my favorite, it at least maintains consistency between method chaining and now function chaining (by pipe).

Re: PHP 8.5 adds pipe operator

#197

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…

Can't the pipe operator be easily mimicked in Ruby thanks to its flexibility?

I'm thinking of something like this:

    class Object
      def |>(fn)
        fn.call(self)
      end
    end
which then can be in the following way:

    result = arr
      |> ->(a) { a.uniq }
      |> ->(a) { a.flatten }
      |> ->(a) { a.map(&:tags) }
Or if we just created an alias for then #then method:

    class Object
      alias_method :|>, :then
    end
then it can be used like in this way:

    arr
      |> :uniq.to_proc
      |> :flatten.to_proc
      |> ->(a) { a.map(&:tags) }

Re: PHP 8.5 adds pipe operator

#198
post #13

Earlier quoted context omitted.

It looks like chaining, but with possibility of adding custom functions?

It's chaining without having to vary the return of each function. In JS you cannot call 3.myMethod(), but you could with 3 |> myMethod

Not only that

In chaining, methods all have to be part of the same class.

In C++ we had this stuff ages ago, it’s called abusing streaming operators LMAO

Re: PHP 8.5 adds pipe operator

#199
post #170

Earlier quoted context omitted.

Haskell seems pretty dead as well. Good think php has another option for line noise though.

What makes you believe Haskell is dead or even dying? New versions of GHC are coming out, and in my experience, developing Haskell has never been smoother (that’s not to say it is completely smooth).

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

Re: PHP 8.5 adds pipe operator

#200
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')…

You're conflating different concepts: familiarity and simplicity.

I don't find the pipe alternative to be much harder to read, but I'd also favour the first one.

In any case, we shouldn't judge software and it's features on familiarity.

Post reply on HN