Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100799
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.15.15 as permitted sender)
To: Sara Golemon <pollita@php.net>, PHP internals <internals@lists.php.net>
References: <CAESVnVo4axBD86qLbXvq4Mb39Dgdx_RQ1rH3KEG8ToaF7CbDag@mail.gmail.com>
Message-ID: <6a857d65-91d7-aba6-0be0-e9c424e34cc3@gmx.de>
Date: Fri, 29 Sep 2017 14:24:22 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <CAESVnVo4axBD86qLbXvq4Mb39Dgdx_RQ1rH3KEG8ToaF7CbDag@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 7bit
Subject: Re: [RFC] Pre-draft for PipeOp v2
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 20.09.2017 at 00:32, Sara Golemon wrote:

> 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