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.
I don't think inspecting this is easier than adding |> IO.inspect() to a pipe chain
PHP 8.5 adds pipe operator
191–200 of 282 posts
Re: PHP 8.5 adds pipe operator
#192The first typed programming language where I've seen pipe operator |> in action was in F#. You can write something like: sum 1 2 |> multiply 3 and it works because |> pushes the output of the left expression as the last parameter into the right-hand function. multiply has to be defined as: let multiply b c = b \* c so that b becomes 3, and c receives the result of sum 1 2 . RHS can also be a lambda too: sum 1 2 |> (f…
Haskell seems pretty dead as well. Good think php has another option for line noise though.
Re: PHP 8.5 adds pipe operator
#193Earlier quoted context omitted.
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) becomes something like 1 (2, (3 |> baz) > bar), 3 |> foo or (3 |> baz) |> (2, % |> bar) |> (1, %, 3 |> foo) That looks like just another way to write a thing in JavaScript, and it is not easier to read. What is the advantage?
Uhm, don't do it, then. That's like arguing that the addition of the ternary operator is a bad one because not all if/else blocks look better when translated into it. The goal is to linearlize unary function application, not to make all code look better.
Re: PHP 8.5 adds pipe operator
#194- pipes make you realize how much song and dance you do for something quite simple. Nesting, interstitial variables, etc all obscuring what is in effect and very orderly set of operations.
- pipes really do have to be a first class operator of the language. I’ve tried using some pipe-like syntactic sugar in languages without pipes and while it does the job, a lot of elegance and simplicity is lost. It feels like you are using a roundabout thing and thus, in the end, doesn’t really achieve the same level of simplicity. Things can get very deranged if you are using a language in a way it wasn’t designed for and even though I love pipes I’ve seen “fake pipes” make things more complicated in languages without them.
Re: PHP 8.5 adds pipe operator
#195Re: PHP 8.5 adds pipe operator
#196I 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')…
$result = $obj->query($sqlQuery)->fetchAll()[$key]
so while the syntax is not my favorite, it at least maintains consistency between method chaining and now function chaining (by pipe).Re: PHP 8.5 adds pipe operator
#197PHP: $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…
I'm thinking of something like this:
class Object
def |>(fn)
fn.call(self)
end
end
which then can be in the following way: result = arr
|> ->(a) { a.uniq }
|> ->(a) { a.flatten }
|> ->(a) { a.map(&:tags) }
Or if we just created an alias for then #then method: class Object
alias_method :|>, :then
end
then it can be used like in this way: arr
|> :uniq.to_proc
|> :flatten.to_proc
|> ->(a) { a.map(&:tags) }Re: PHP 8.5 adds pipe operator
#198Earlier quoted context omitted.
It looks like chaining, but with possibility of adding custom functions?
It's chaining without having to vary the return of each function. In JS you cannot call 3.myMethod(), but you could with 3 |> myMethod
In chaining, methods all have to be part of the same class.
In C++ we had this stuff ages ago, it’s called abusing streaming operators LMAO
Re: PHP 8.5 adds pipe operator
#199Earlier quoted context omitted.
Haskell seems pretty dead as well. Good think php has another option for line noise though.
What makes you believe Haskell is dead or even dying? New versions of GHC are coming out, and in my experience, developing Haskell has never been smoother (that’s not to say it is completely smooth).
Mind you, I know and like Haskell, but its issues are highly tied to the failure of the simple haskell initiative (also the dreadful state of its tooling).
Re: PHP 8.5 adds pipe operator
#200I 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 don't find the pipe alternative to be much harder to read, but I'd also favour the first one.
In any case, we shouldn't judge software and it's features on familiarity.