I was planning to update the RFC, but wiki.php.net is having issues
atm and isn't coming back up with basic coaxing, so I'll just start
discussion informally, and the RFC can be updates later.

Background: I made an RFC some time ago to implement HackLang's Pipe
Operator https://docs.hhvm.com/hack/operators/pipe-operator which
provides fluent calling for non-object interfaces.
I circulated it to mixed reviews, many negative, with the negativity
feeling like it centered on the use of a magic placeholder token $$.

After discussion with Levi and others who suggested a simpler
approach, I'd like to offer
https://github.com/php/php-src/compare/master...sgolemon:pipe2 as an
alternate possibility.

This version removes the $$ token, and instead treats the RHS of the
expression as a callable obeying the same rules as the callable
typehint elsewhere in the language. Specifically:

• Free functions as strings containing the function name. (e.g. 'funcname')
• Object methods as array($object, 'methodname')
• Static methods as array('Classname', 'methodname')
• Closure expression (e.g. function($x) { return ...; } )
• Object instance with an __invoke() method.

In a given pipe expression, the output of the LHS expression feeds a
single arg to the callable on the RHS.
Examples:

$x = "hello"
|> 'strtoupper'
|> function($x) { return $x . " world"; };
// $x === "HELLO world"

Non-Goal: I didn't include support for base function names (e.g.
"hello" |> strtoupper) because of the conflict with constants.
Using a constant to store your function name is totes legit and
consistent with language syntax.

Future Scope: Short Lambdas $x => $x + 1 and Partial Functions
someFunc('fixed val1', ..., 'fixed val2') would help make this
functionality more useful and are worth discussing as a sub-thread,
but are not required to be implemented at the same time.

-Sara

Thank you for making this proposal! As alluded to I had concerns on
the original proposal and fully support this version. Sometimes
simplicity is the mark of a good RFC and I think this is one of those
times.

I was planning to update the RFC, but wiki.php.net is having issues
atm and isn't coming back up with basic coaxing, so I'll just start
discussion informally, and the RFC can be updates later.

Background: I made an RFC some time ago to implement HackLang's Pipe
Operator https://docs.hhvm.com/hack/operators/pipe-operator which
provides fluent calling for non-object interfaces.
I circulated it to mixed reviews, many negative, with the negativity
feeling like it centered on the use of a magic placeholder token $$.

After discussion with Levi and others who suggested a simpler
approach, I'd like to offer
https://github.com/php/php-src/compare/master...sgolemon:pipe2 as an
alternate possibility.

This version removes the $$ token, and instead treats the RHS of the
expression as a callable obeying the same rules as the callable
typehint elsewhere in the language. Specifically:

• Free functions as strings containing the function name. (e.g. 'funcname')
• Object methods as array($object, 'methodname')
• Static methods as array('Classname', 'methodname')
• Closure expression (e.g. function($x) { return ...; } )
• Object instance with an __invoke() method.

In a given pipe expression, the output of the LHS expression feeds a
single arg to the callable on the RHS.
Examples:

$x = "hello"
|> 'strtoupper'
|> function($x) { return $x . " world"; };
// $x === "HELLO world"

Non-Goal: I didn't include support for base function names (e.g.
"hello" |> strtoupper) because of the conflict with constants.
Using a constant to store your function name is totes legit and
consistent with language syntax.

Future Scope: Short Lambdas $x => $x + 1 and Partial Functions
someFunc('fixed val1', ..., 'fixed val2') would help make this
functionality more useful and are worth discussing as a sub-thread,
but are not required to be implemented at the same time.

I think this feature makes very little sense if it's not introduced
together with a way of making partial application much more ergonomic than
it is now. I understand the desire to keep things separate, but I don't
think that this proposal can land without partial application syntax being
introduced beforehand or in conjunction with it.

From a previous R11 discussion, I remember that two strong contenders were
foo(...) for getting a callable with an arbitrary number of unbound
parameters and foo($$) for a single unbound parameter. In the latter case
the proposal has a similar expressive power as the previous pipe operator
proposal. Another option was to make $$ a more general construct for
obtaining single-parameter closures in compact form. Then you would also be
able to write "$$->getFoo()" to get the equivalent of "function($x) {
return $x->getFoo(); }" and similar. A disadvantage is that the precedence
here is less clear and that a short closure syntax might be more clear for
the cases that go beyond partial application.

Regards,
Nikita

Posted 3 years ago by Sara Golemon — view source

After discussion with Levi and others who suggested a simpler
approach, I'd like to offer
https://github.com/php/php-src/compare/master...sgolemon:pipe2 as an
alternate possibility.

I am still feeling it is a bit weird to do things that way, but other
than that (which is just my personal issue) I do not see any problems in
this proposal. With magic weird $$ thing gone, it seems to be
straightforward and mostly intuitive. So while I am not feeling this is
a must, I think it may be nice to have it.

It'd be also nice then if we could have some syntax that allowed us to
refer to functions/methods as callables - mostly for the benefit of the
code readers and IDEs. I.e. you can do "hello" |> "strtoupper" and it's
fine but it is not at all intuitive what you're doing sending one string
into another. Same with "hello" |> [$this, 'bar']. Now, if we could do
something like this:
"hello" |> &{strtoupper}
"hello" |> &{$this->bar}

(yes I know the syntax is ugly, I hope you get the idea though to have a
syntax for this) then you could have better readability, easier IDE
autocompletion and other benefits. Not for this RFC, clearly, but just
putting it out there so I don't forget.

--
Stas Malyshev
[email protected]

I was planning to update the RFC, but wiki.php.net is having issues
atm and isn't coming back up with basic coaxing, so I'll just start
discussion informally, and the RFC can be updates later.

Background: I made an RFC some time ago to implement HackLang's Pipe
Operator https://docs.hhvm.com/hack/operators/pipe-operator which
provides fluent calling for non-object interfaces.
I circulated it to mixed reviews, many negative, with the negativity
feeling like it centered on the use of a magic placeholder token $$.

After discussion with Levi and others who suggested a simpler
approach, I'd like to offer
https://github.com/php/php-src/compare/master...sgolemon:pipe2 as an
alternate possibility.

This version removes the $$ token, and instead treats the RHS of the
expression as a callable obeying the same rules as the callable
typehint elsewhere in the language. Specifically:

• Free functions as strings containing the function name. (e.g. 'funcname')
• Object methods as array($object, 'methodname')
• Static methods as array('Classname', 'methodname')
• Closure expression (e.g. function($x) { return ...; } )
• Object instance with an __invoke() method.

In a given pipe expression, the output of the LHS expression feeds a
single arg to the callable on the RHS.
Examples:

$x = "hello"
|> 'strtoupper'
|> function($x) { return $x . " world"; };
// $x === "HELLO world"

Non-Goal: I didn't include support for base function names (e.g.
"hello" |> strtoupper) because of the conflict with constants.
Using a constant to store your function name is totes legit and
consistent with language syntax.

I'm not particularly fond of a pipe(line) operator. I don't see a great
advantage over a simple compose function:

$appendWorld = function ($x) {return "$x world";};
$x = compose('strtoupper', $appendWorld)('hello');

The benefit of using a compose function would be the possibility of
point-free programming without explicitely declaring another function:

$toUpperAppendWorld = compose(
'strtoupper',
function ($x) {return "$x world";}
);
$x = $toUpperAppendWorld('hello');
$y = $toUpperAppendWorld('goodbye');

Basically, the compose function would be like the pipe operator without
special casing the (first) input.

See also Andreas's suggestion regarding built-in functions for common
functional primitives (http://news.php.net/php.internals/100739).

--
Christoph M. Becker