Every language should have this.
Forget about transforming existing code, it makes new code much more reasonable (the urge to come up with OOPslop is much weaker when functions are trivial) — they're programming languages for a reason.
PHP 8.5 adds pipe operator
121–130 of 282 posts
Re: PHP 8.5 adds pipe operator
#122Earlier quoted context omitted.
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?
Deployment these days is essentially git pull && composer update
Of course not if you use vm or serverless or whatever like this, but for a basic here is my crude app, that's what you do.
Or if you want to go old school sure, just scp that directory, it still works like it did 30 years ago.
Re: PHP 8.5 adds pipe operator
#123i wish python had something liek that to be honest
one can dream but i wouldn't keep high hopes. I feel functional patterns are left as second class citizens in python.
Re: PHP 8.5 adds pipe operator
#124Earlier 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…
The pipe syntax is much more readable than nested function calls when you need additional arguments for intermediate functions. With nested functions it becomes hard to see which functions those arguments belong to even if you try to help it with formatting.
Re: PHP 8.5 adds pipe operator
#125Meanwhile 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.
If your team prefers not to use this new optional feature, just enable a PHPStan rule in your CI/CD pipeline that prevents code like this getting merged.
Re: PHP 8.5 adds pipe operator
#126This looks neat. However since I read about Koka's dot selection [0], I keep thinking that this is an even neater syntax: fun showit( s : string ) s.encode(3).count.println However, this is of course impossible to implement in most languages as the dot is already meaningful for something else. [0] https://koka-lang.github.io/koka/doc/book.html#sec-dot
That syntax is very clean when it works. I think however the limitation of not being able to pipe arguments into 2nd, 3rd, ..., positions and keyword arguments, or variadic explosion like the syntax showcased in the article makes it less powerful. Are there other syntax helpers in that language to overcome this?
It still makes sense to have a clean syntax for the simple case. You can use currying (with or without first class language support) to handle more complex cases or just fall back to good old function composition or even loops.
Re: PHP 8.5 adds pipe operator
#127Earlier quoted context omitted.
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?
They can't implement function application without tanking performance? I find that hard to believe. Especially considering that function application is already a commonly used (and, dare I say: essential) feature in the language, eg: `Math.sqrt(2)`. All we're asking for is the ability to rewrite that as `2 |> Math.sqrt`. What they're afraid of, my understanding goes, is that people hypothetically , may start leaning…
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)
1 (2, (3 |> baz) > bar), 3 |> foo
(3 |> baz) |> (2, % |> bar) |> (1, %, 3 |> foo)
Re: PHP 8.5 adds pipe operator
#128Why not just make types psuedo-objects? $myString.trim().replace("w", "h"); Which has the advantage of also offering a clean alternative to the fragmented stdlib.
Because duplicating the stdlib is probably not a good idea.
Re: PHP 8.5 adds pipe operator
#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($_)
I am skeptical to these types of sugar. Often what you really want is an iterator. The ability to hide that need carries clear risk.
Re: PHP 8.5 adds pipe operator
#130This will be the year of PHP. People are tired of JS.
I'm not a fan of it, but JavaScript will outlive me.