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

51–60 of 282 posts

Re: PHP 8.5 adds pipe operator

#51

Post by foul »

phplovesong wrote: post #16

The stdlib is so inconsistent this will be a nightmare. Optionally with a better language you know what order params as passed (array_map / array_filter), but in PHP its an coin toss. This feels very bolted on and not suited for the stdlib at all. PHP devs should instead FIRST focus on full unicode support (no, the mb_real_uppercase wont do), and only then focus on a new namespaced stdlib with better design.

>The stdlib is so inconsistent this will be a nightmare.

I think that callables will end with being useless in this context and everyone will pipe closures to put that $x wherever the stdlib imposes.

Re: PHP 8.5 adds pipe operator

#52

Post by andrewflnr »

someothherguyy wrote: post #46
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'))));

> It's so much easier to reason about Is it though? I don't think so.

It tends to work a little better in Elixir, because you very rarely have to include one-off lambdas in your pipeline. The standard library functions are designed to work with the pipeline operator, where the thing you probably want to thread through is usually the first argument.

Re: PHP 8.5 adds pipe operator

#53

Post by qwertox »

r34 wrote: post #48
qwertox wrote: 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.

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( ...array_column($arr, 'tags') ) ) );
or

   array_values(
     array_unique(
       array_merge(
         ...array_column($arr, 'tags')
       )
     )
   );

Re: PHP 8.5 adds pipe operator

#54

Post by avaq »

bapak wrote: post #2

Meanwhile the JS world has been waiting for 10 years for this proposal, which is still in stage 2 https://github.com/tc39/proposal-pipeline-operator/issues/23...

Not only have we been waiting for 10 years, the most likely candidate to go forward is not at all what we wanted when the proposal was created:

We wanted a pipe operator that would pair well with unary functions (like those created by partial function application, which could get its own syntax), but that got rejected on the premise that it would lead to a programming style that utilizes too many closures[0], and which could divide the ecosystem[1].

Yet somehow PHP was not limited by these hypotheticals, and simply gave people the feature they wanted, in exactly the form it makes most sense in.

[0]: https://github.com/tc39/proposal-pipeline-operator/issues/22... [1]: https://github.com/tc39/proposal-pipeline-operator/issues/23...

Re: PHP 8.5 adds pipe operator

#55

Post by LeonM »

kijin wrote: post #35
phatskat wrote: post #26

Earlier quoted context omitted.

I actually don’t mind them, and I’ve been out of daily PHP work for a few years now. When I see people denote internal variables with _ or elements with $ in JS, it rubs me the wrong way, but in PHP the $ is kind of nice. I also prefer the look of ->, it’s _cool_

Other languages have all sorts of oversized arrows, like ==> and >>>. -> in PHP and C++ looks clean by comparison. I'll never forgive them for the brain fart they made of the namespace separator, though.

> I'll never forgive them for the brain fart they made of the namespace separator, though.

You mean the backslash? What's wrong with that?

Re: PHP 8.5 adds pipe operator

#58

Post by eurleif »

exasperaited wrote: post #41
Einenlum wrote: post #33

Earlier quoted context omitted.

They're not though. array_filter takes (arr, callback) https://www.php.net/manual/en/function.array-filter.php array_map takes (callback, arr) https://www.php.net/manual/en/function.array-map.php

This is "english-sentence-order-consistent", as it goes. Array filter is "filter this array with this function". Array map is "map this function over this array". But I agree any replacement function should be consistent with Haskell.

One can construct English sentences in the opposite order. There is no singular "English sentence order".

"Filter for this function in this array"

"Map over this array with this function"

Re: PHP 8.5 adds pipe operator

#59

Post by quietbritishjim »

mappu wrote: post #57

Every single one of those steps buffers into a temporary variable - this isn't efficient like a bash pipe.

Genuine question from a non-PHP user:

Does PHP support iterator-like objects? Like Python I mean, where mydict.values() produces values on demand, not immediately realised as a list. Or are all steps necessarily guaranteed to be fully realised into a complete list?

Re: PHP 8.5 adds pipe operator

#60

Post by r34 »

girvo wrote: post #50
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.

> 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:)
Post reply on HN