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

181–190 of 282 posts

Re: PHP 8.5 adds pipe operator

#181

Post by troupo »

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

> I think the syntax is much more complicated to read, requiring backtracking to understand.

Same as with `array_merge(...array_column($arr, 'values'));` or similar nested function calls.

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

We don't have to imagine :) People working in languages supporting pipes look at similar code all day long.

> but the self-documentating nature of a couple variables defining what things are or are doing seems important to writing maintainable code

Pipes do not prevent you from using a couple of variables.

In your example I need to keep track of $values variable, see where it's used, unwrap nested function calls etc.

Or I can just look at the sequential function calls.

What PHP should've done though is just pass the piped value as the first argument of any function. Then it would be much cleaner:

  $result = $arr
    |> array_column('values')
    |> array_merge()
    |> array_reduce(fn($carry, $item) => $carry + $item, 0)
    |> fn($x) => str_repeat('x', $x);
I wouldn't be surprised if that's what will eventually happen

Re: PHP 8.5 adds pipe operator

#182

Post by gbalduzzi »

colecut wrote: post #29
gbalduzzi wrote: post #9

I like it. I really believe the thing PHP needs the most is a rework of string / array functions to make them more consistent and chain able. Now they are at least chainable. I'm not a fan of the ... syntax though, especially when mixed in the same chain with the spread operator

PHP string / array functions are consistent. string functions use (haystack, needle) and array functions use (needle, haystack) because that's the way the underlying C libraries also worked

`strlen`, `strncmp` and `strtolower` but `str_split` and `str_contains`.

How it that consistent?

Re: PHP 8.5 adds pipe operator

#183

Post by [deleted] »

hnlmorg wrote: post #78
exasperaited wrote: post #65

Earlier quoted context omitted.

Right, but these are both more unwieldy. One filters something with something else, in the real world. Filter water with a mesh etc. And (in maths, at least) one maps something onto something else. (And less commonly one maps an area onto paper etc.) Just because you can make your two sentences does not make them natural word order.

When you consider that PHP is used by hundreds of thousands of non-native English speakers, I don’t really think you can make a legitimate claim that “English sentence order” trumps “consistent argument ordering”. There’s enough viral videos online of how even neighbouring European counties order common sentences differently. Even little things like reading the time (half past the previous hour vs half to the next ho…

[deleted]

Re: PHP 8.5 adds pipe operator

#184

Post by troupo »

qwertox wrote: post #53
r34 wrote: post #48

Earlier quoted context omitted.

Your version includes 4 variables. Pipes don't create those intermediate variables, so they are more memory efficient. Readability is mostly matter of habit. One reads easily what he/she is used to read.

It's true that pipes are more readable, and for many cases they will be the better option, but the example of nested functions just doesn't hold. That's like saying someone would use this: $result = $arr |> fn($x) => array_column($x, 'tags') |> fn($x) => array_merge(...$x) |> array_unique(...) |> array_values(...) which is harder to reason about than the nested functions. array_values( array_unique( array_merge( ...a…

Why didn't you format the pipes, too?

  $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')
       )
     )
   );
With pipes you have linear sequence of data transformations. With nested function calls you have to start with innermost function and proceed all the way top the outermost layer.

Re: PHP 8.5 adds pipe operator

#185

Post by troupo »

chuck8088 wrote: post #169

This article makes a great case WHY the pipe operator is useful, but why didn't they just rewrite those functions to support method chaining? ` $profit = [1, 4, 5] .loadSeveral() .filter(isOnSale()) .map(sellWidget()) .array_sum(); ` this has the side benefit of 'looking normal'

Because pipes work on all functions, not just object methods. So your business logic, validations etc. don't have to be methods of the built-in objects.

And there's nothing abnormal about pipes

Re: PHP 8.5 adds pipe operator

#186

Post by chuckadams »

Y-bar wrote: post #79
colecut wrote: post #29

Earlier quoted context omitted.

PHP string / array functions are consistent. string functions use (haystack, needle) and array functions use (needle, haystack) because that's the way the underlying C libraries also worked

> because that's the way the underlying C libraries also worked I feel like this is a weak defence of the internally inconsistent behaviour. As someone who has been programming with PHP for over twenty years now, most of them professionally, I still cannot remember the needle/haystack order in these functions, I thank intellisense for keeping me sane here. As evident with this pipe operator, or with for example Attri…

It's not so much a defense as it is an explanation of the historical origins. Even the creator of the language doesn't defend the inconsistencies and admits that they were a mistake. PHP also takes backward compatibility pretty seriously and doesn't rearrange things for consistency's sake alone.

Re: PHP 8.5 adds pipe operator

#188

Post by Mystery-Machine »

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.

Re: PHP 8.5 adds pipe operator

#190

Post by layer8 »

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

I completely agree about intermediate variables (and with explicit type annotations in a typed language) to make the code more intelligible.

But maybe also, the pipe syntax would be better as:

    $arr
    |> fn($x) => array_column($x, 'values')
    |> fn($x) => array_merge(...$x)
    |> fn($x) => array_reduce($x, fn($carry, $item) => $carry + $item, 0)
    |> fn($x) => str_repeat('x', $x)
    |= $result;
Post reply on HN