Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93033
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <82.BC.03860.FA5F7275@pb1.pair.com>
To: internals@lists.php.net
References: <CAESVnVpa5j=fagr-wm5+DzKKX=wzTN1p8+Kv3-KtGpuyH51b0A@mail.gmail.com>
 <8ea990da-1fe7-256c-4e08-0b30715c8e8a@gmail.com>
 <5724F3F8.5070909@garfieldtech.com>
Date: Mon, 2 May 2016 19:49:47 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <5724F3F8.5070909@garfieldtech.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Pipe Operator
From: me@stephencoakley.com (Stephen Coakley)

On 04/30/2016 01:05 PM, Larry Garfield wrote:
> On 04/29/2016 07:19 PM, Stanislav Malyshev wrote:
> In a way... Sara, this syntax feels like it's only one step removed from
> promises; if any of the chained steps involve IO, it becomes basically
> what promises are for.  Am I barking down the wrong tree, or is there
> something we could connect there?  (I don't mean "reject this in favor
> of promises", but more "is there something we can do here to be forward
> thinking, since lots of people want to see async in core PHP?")
>
> --Larry Garfield

I see the connection to promises too; it's not just you :)

I might be thinking about it wrong, but I think that "one step" you're 
looking for is handling the failure case (Sara kinda mentioned it in a 
later post). Promises are essentially matching two cases: 
Success/Ok/Some, and Failure/Error/None. This RFC seems to only handle 
the first case. Sure, you could use exception handling:

try {
     $ret = scandir($arg)
         |> array_filter($$, function($x) { return $x !== '.' && $x != 
'..'; })
         |> array_map(function ($x) use ($arg) { return $arg . '/' . $x; 
}, $$)
         |> getFileArg($$)
         |> array_merge($ret, $$);
catch (Throwable $e) {
}

But not all failures or "errors" are actually exceptions. I'm not sure 
how to approach this cleanly without monads, really.

The other issue is with closures and callbacks. Unless, at some point in 
the future when the heroes of PHP gift us with async in the core pipe 
operator is redefined, async operations need to be resumable later.

Consider a small hypothetical I/O example:

$data = new Socket()
     |> (function ($socket) {
	   // Um, how do I yield/await here? The next pipe function
            // expects an immediate return...
            return $socket->connect(/* ... */);
        })($$)                      // <-- also, this is awkward...
     |> readUntil($$, '\n')

The benefit of promises is that everything is eventually defined in 
terms of callbacks. That way things can be executed whenever. From my 
understanding (correct me if I'm wrong) the pipe operator does not 
enable this.

Also, +1 for the idea, and +1 for considering the promises case! Using 
the pipe operator for async operations would be super cool!

-- 
Stephen