Sorry, that's my first reply to mailing list discussion, maybe i'm not
doing it right.
Ilija wrote:
The problem you're describing is not unique to pipes. Code like this
is quite common. $x = foo() ->bar() ->baz(); If we decide this is a
problem (which I fundamentally disagree with), then we should try to
find a general solution, rather than something that is specific to
pipes. There's no reason why this example shouldn't work. foo()
->bar() ->baz() |>= $x; At that point, you should probably also look
for an operator that isn't pipe-specific. But again, I disagree with
the premise that this is a problem to begin with.
You're providing some fluent-like syntax as example of situation. Foobar
example does not show all posible use cases. Compare, two code blocks,
they are read differently even same syntax.
// no need to replace with pipe operator.
// you even will not try to wrap such code to improve readability.
Little chance structure will change in future, order of call could not
be changed.
// no need of left to right assignment in this case. Little chancethat
expression will grow more than 2-3 lines.
$x = $movies->getMovie()->getCharacters()->getCharacter()
// complex structure access, inspired by (inspired by
https://www.php.net/manual/en/simplexml.examples-basic.php)
$y = collect($strings)->trim()->toUpper()->implode(',');
// Fluent chain of calls. this case is what pipe operator for.
// you will probably want to wrap this line to improve readability.
Order of processing is point of further changes. List can grow, leading
to 10-15 lines of piped function calls, if some map calls or other
transformations are added.
In fluent we even can write foo()->bar()->baz()->assignTo($x) (as it's
user-defined method, we can make any logic). With fluent we do not need
nor pipe, nor ltr-assignment. But someone thought fluent syntax is not
good, as this is not native language operator, but a wrapper pattern,
and we have pipe operator now.
But we must remember that fluent syntax appeared precisely because the
language did not have tools to record the order of calls from left to
right and top to bottom. From a programming language perspective, fluent
syntax is just a chain of calls.
The appearance of such an language element as the pipe operator in the
programming language proves that the need for reading the calls from
left to the right existed. And this need is dictated precisely by our
perception of the code, and not by some technical need.
This also proves that we have same need of left-to-right assignment
operator, caused by same feature of human perception.
My proposal is about need of left to right assignment operator together
with left to right function call operator. As idea was inspired by pipe
operator rfc, so i chosed operator most looked like pipe. If the pipe
symbol distracts from the essence, lets' discuss some other symbol, e.g. -->
$x --> $y;
$strings
|> 'trim'
|> 'toUpper'
|> implode(',', ...)
--> $y
foo()
->bar()
->baz() --> $x;
The current bahavior of pipe operator when used with variable is wery poorly
described in RFC
That's not quite accurate. It states:
The left-hand side of the pipe may be any value or expression.
And according to PHPs expression model, variables get no special
treatment. They are evaluated and the result is used accordingly,
pipes are not special at all in that regard.
You're speaking about left-hand side of operator. I'm speaking about
case, where variable is in the right side of pipe operator. RFC contains
no examples, where there's variable, storing callable. Even without my
proposal, this should be clarified in documentation on pipe operator.
Expression $x |> $y can mislead.
