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

111–120 of 282 posts

Re: PHP 8.5 adds pipe operator

#111

Post by exasperaited »

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…

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

Well that’s good, because I didn’t.

Re: PHP 8.5 adds pipe operator

#112

Post by ptx »

mort96 wrote: post #91

I'm surprised that the example requires lambdas... What's the purpose of the `|> foo(...)' syntax if the function has to take exactly one operand? Why is it necessary to write this? $arr |> fn($x) => array_column($x, 'tags') Why doesn't this work? $arr |> array_column(..., 'tags') And when that doesn't work, why doesn't this work? $arr |> array_unique

Apparently "foo(...)" is just the PHP syntax for a function reference, according to the "first-class callable" RFC [1] linked from the article.

So where in Python you would say e.g.

  callbacks = [f, g]
PHP requires the syntax

  $callbacks = [f(...), g(...)];
As for the purpose of the feature as a whole, although it seems like it could be replaced with function composition as mentioned at the end of the article, and the function composition could be implemented with a utility function instead of dedicated syntax, the advantage of adding these operators is apparently [2] performance (fewer function calls) and facilitating static type-checking.

[1] https://wiki.php.net/rfc/first_class_callable_syntax

[2] https://wiki.php.net/rfc/function-composition#why_in_the_eng...

Re: PHP 8.5 adds pipe operator

#113

Post by chilmers »

wouldbecouldbe wrote: post #3
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...

It’s really not needed, syntax sugar. With dots you do almost the same. Php doesn’t have chaining. Adding more and more complexity doesn’t make a language better.

I'm tired of hearing the exact same arguments, "not needed", "just syntax sugar", "too much complexity", about every new syntax feature that gets added to JS. Somehow, once they are in the language, nobody's head explodes, and people are soon using them and they become uncontroversial.

If people really this new syntax will make it harder to code in JS, show some evidence. Produce a study on solving representative tasks in a version of the language with and without this feature, showing that it has negative effects on code quality and comprehension.

Re: PHP 8.5 adds pipe operator

#114

Post by allan_s »

Einenlum wrote: post #36
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.

This. We definitely need a better stdlib with appropriate data structures

it's a chicken and the egg problem

I think initiative like this drive a need for a more consistent, and even if slow, PHP has been deprecated/reworking its stdlib so I'm hopeful on this.

Re: PHP 8.5 adds pipe operator

#115

Post by nolok »

defraudbah wrote: post #84

PHP is that weird beast that no one wants to praise and yet it works tremendously well for those who manage to tame it. I would likely never touch it as there are too many languages to use and what I know is more than enough to do my job, but I am super excited to see languages like PHP that aren't mainstream in my bubble to keep evolving

I'm not tempting you do to it or anything, but I want to say given your point of view, if one day you need a crude+ app and try to do it using laravel, you might be really surprised by what modern php actually is.

There was a point were I thought the language and it ecosystem was going down the drain but then they recovered and modern php is 90% what do you want to do and don't worry about the how, it's easy.

I don't use it much anymore, but every time I do all I see are possibilities.

Re: PHP 8.5 adds pipe operator

#116

Post by nolok »

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.

Because back compat' is a very strong feature of the language, same reason "match" was created instead of replacing switch.

As a result, taking a php 5.2 script and moving it up to 8.5 is super easy, and taking a PHP 4 one is barely harder only longer (since it probably uses the horrors that were register_globals and co).

Ultimately, I prefer this than a fragmented ecosystem impossible to resolve.

Re: PHP 8.5 adds pipe operator

#117

Post by jeroenhd »

lexicality wrote: post #73
avaq wrote: post #54

Earlier quoted context omitted.

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 whi…

Am I correct in my understanding that you're saying that the developers of the most widely used JS engine saying "hey we can't see a way to implement this without tanking performance" is a silly hypothetical that should be ignored?

With JS' async/await system basically running on creating temporary closures, I don't think things will change all that much to be honest.

Furthermore, I don't see why engines should police what is or isn't acceptable performance. Using functional interfaces (map/forEach/etc.) is slower than using for loops in most cases, but that didn't stop them from implementing those interfaces either.

I don't think there's that much of a performance impact when comparing

    const x = fun1(abc);
    const y = fun2(x);
    const z = fun3(y);
    fun4(z);
and

    abc |> fun1 |> fun2 |> fun3 |> fun4
especially when you end up writing code like

    fun1(abc).then( (x) => fun2(x)).then( (y) => fun3(y)).then((z) => fun4(z))
when using existing language features.

Re: PHP 8.5 adds pipe operator

#118

Post by hn8726 »

sandreas wrote: post #4

While I appreciate the effort and like the approach in general, in this use case I really would prefer extensions / extension functions (like in Kotlin[1]) or an IEnumerable / iterator approach (like in C#). $arr = [ new Widget(tags: ['a', 'b', 'c']), new Widget(tags: ['c', 'd', 'e']), new Widget(tags: ['x', 'y', 'a']), ]; $result = $arr |> fn($x) => array_column($x, 'tags') // Gets an array of arrays |> fn($x) => ar…

Kotlin also has extensions function `let` (and a couple of variants) which let you chain arbitrary methods:

``` val arr = ... val result = arr .let { column(it, "tags") .let { merge(it) } .let { unique(it) } .let { values(it) } ```

You add function references for single-argument functions too:

``` arr.let(::unique) // or (List::unique), depends on the function ```

all without adding a special language construct.

Re: PHP 8.5 adds pipe operator

#119

Post by defraudbah »

nolok wrote: post #115
defraudbah wrote: post #84

PHP is that weird beast that no one wants to praise and yet it works tremendously well for those who manage to tame it. I would likely never touch it as there are too many languages to use and what I know is more than enough to do my job, but I am super excited to see languages like PHP that aren't mainstream in my bubble to keep evolving

I'm not tempting you do to it or anything, but I want to say given your point of view, if one day you need a crude+ app and try to do it using laravel, you might be really surprised by what modern php actually is. There was a point were I thought the language and it ecosystem was going down the drain but then they recovered and modern php is 90% what do you want to do and don't worry about the how, it's easy. I don't…

what about deployment? I assume I need to scp files like Python or keep everything in a single giant PHP file? is that an option?

Re: PHP 8.5 adds pipe operator

#120

Post by simonask »

dev_l1x_be wrote: post #77

Rust is next? Jokes aside, pipe operators in programming languages have a interesting side effect of enabling railway oriented programming that I miss the most when not working in F#.

The way function/trait resolution works in Rust, it's actually already quite idiomatic to code in this style (just using the dot operator). The standard library Iterator is a great example of this. :-)

I don't think there's any significant push for an even terser syntax at the moment.

Post reply on HN