Why 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.
PHP 8.5 adds pipe operator
21–30 of 282 posts
Re: PHP 8.5 adds pipe operator
#22Meanwhile 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.
Dots call functions on objects, pipe passes arguments to functions. Totally missing the point.
Re: PHP 8.5 adds pipe operator
#23I tried to emulate something similar with PHP at one point. But the problem with PHP was parameter order. Especially in functions like array_key_exists() the array element is the 2nd parameter, while pipe operator expects the object to work on be the 1st parameter, the array in these cases.
I believe they have solved this problem by now. Though no idea how.
Re: PHP 8.5 adds pipe operator
#24Re: PHP 8.5 adds pipe operator
#25While 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…
PHP has traits, just invent that API, put it in a trait and add it to your data classes.
Re: PHP 8.5 adds pipe operator
#26Why 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.
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_
Re: PHP 8.5 adds pipe operator
#27I 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
Agree, the ... syntax feels confusing when each fn($x) in the example uses $x as the name of its argument.
My initial instinct would be to write like this:
`$result = $arr
|> fn($arr) => array_column($arr, 'tags') // Gets an array of arrays
|> fn($cols) => array_merge(...$cols)`
Re: PHP 8.5 adds pipe operator
#28Meanwhile 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...
in typescript we can do this
let res res = op1() res = op2(res.op1) res = op3(res.op2)
type inference works great, and it is very easy to debug and refactor. In my opinion even more than piping results.
Javascript has enough features.
Re: PHP 8.5 adds pipe operator
#29I 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
Re: PHP 8.5 adds pipe operator
#30"A major limitation of the pipe operator is that all the callables in the chain must accept only one required parameter.
For built-in functions, if the function does not accept any parameters, it cannot be used in a chain. For user-land PHP functions, passing a parameter to a function that does not accept any parameters does not cause an error, and it is silently ignored.
With the pipe operator, the return value of the previous expression or the callable is always passed as the first parameter to the next callable. It is not possible to change the position of the parameter."
https://php.watch/versions/8.5/pipe-operator
In the light of these limitations I would not call the Elixir implementation "slightly fancier".
I'm not so sure I'll be upgrading my local PHP version just for this but it's nice that they are adding it, I'm sure there is a lot of library code that would look much better if rewritten into this style.