Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93119
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.43 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <fe837e8b-2a6e-516e-33f0-cfcca172d565@fleshgrinder.com>
References: <CAESVnVpa5j=fagr-wm5+DzKKX=wzTN1p8+Kv3-KtGpuyH51b0A@mail.gmail.com>
 <4fc01507-3d07-2309-a4e4-4cad7325249b@gmail.com> <AA.0D.03860.787F7275@pb1.pair.com>
 <CA+CPB82OUEzCQibp5YezVaT8PwOF6fXb2Fb39oKL5fPKwX-kRw@mail.gmail.com>
 <bb8bdb06-b9e5-7e02-3aa5-d54121b8eacb@fleshgrinder.com> <CAESVnVpFCN-cC1pyiZ+ApOneUagb9ncUfOHqhNtE+WQaBkH_TA@mail.gmail.com>
 <39071a01-a42c-0952-b3a8-b4769c79b56b@fleshgrinder.com> <CAESVnVpwbYdeENZ4CW1m8KiLSZv87x5TO3+72uYYR262rgYL3Q@mail.gmail.com>
 <0ac3be89-6fb4-610a-ef89-0928f264f96c@fleshgrinder.com> <CAESVnVpBn2fpK-BQXj2261mTMG7ZUK1XwOS6jZn1wiYBEs61mg@mail.gmail.com>
 <71379db5-b7b8-78b3-ada5-eee34e6e22d6@fleshgrinder.com> <CAObuZdtS-gn3gT6L2bwshF4H9KzxZSaCsu41CYtyeT+=SOCSyg@mail.gmail.com>
 <a25612f2-fb09-c25e-ca30-daf850acaa96@fleshgrinder.com> <CAObuZduo2-mnZMbgKFEWN1=yxqgqh_8RCN7GSpCTYCNXVjWJ_w@mail.gmail.com>
 <fe837e8b-2a6e-516e-33f0-cfcca172d565@fleshgrinder.com>
Date: Mon, 9 May 2016 11:04:40 +0900
Message-ID: <CAGa2bXaKWu+WJ7unZ2TfG03KUYY3JyNG=FK3cUbR3PL244znyA@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Cc: Ryan Pallas <derokorian@gmail.com>, Sara Golemon <pollita@php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Pipe Operator
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi,

I agree they are bad APIs.
Framework/library developer should provide better API

On Mon, May 9, 2016 at 1:08 AM, Fleshgrinder <php@fleshgrinder.com> wrote:
>   $request = getGlobals()
>     |> parseRequest($$)
>     |> buildPsr7Request($$);

should be

require('some.lib');
$request = getRequest();

/* where getRequest() is
function getRequest() {
   return getGlobals()
     |> parseRequest($$)
     |> buildPsr7Request($$);
}
*/

>
>   $response = loadConfig()
>     |> buildDic($$)
>     |> getApp($$)
>     |> getRouter($$)
>     |> getDispatcher($$, $request)
>     |> dispatchBusinessLogic($$, $request, new Response())
>     |> renderResponse($$)
>     |> buildPsr7Response($$)
>     |> emit($$);

should be

require('some.lib');
$request = getRequest();
$response = getResponse($request);

/* where getResponse() is
function getRequest($request) {
   return loadConfig()
     |> buildDic($$)
     |> getApp($$)
     |> getRouter($$)
     |> getDispatcher($$, $request)
     |> dispatchBusinessLogic($$, $request, new Response())
     |> renderResponse($$)
     |> buildPsr7Response($$)
     |> emit($$);
}
*/

> Suddenly I magically need to know how all of that procedural stuff goes
> together just to be able to keep it short while calling all of it?!?
>
> I hope you understand now why I am still asking for real world examples
> that are not based on endlessly bad code.

"|>" is just a building block for simpler coding. It could be used badly, but
it helps a lot. Procedural code could be much simpler and readable with "|>".

function getRequest() {
   $config = loadConfig();
   $dic = buildDic($config);
   $app = getApp($dic);
   $route = getRouter($app);
   $dispatcher = getDispatcher($route, $request);
   $businessLogic = dispatchBusinessLogic($dispatcher, $request, new
Response());
   $resp =  renderResponse($businessLogic);
   $response = buildPsr7Response($resp);
    return emit($response);
}

"|>" version is much easier to read and write.
I suppose most users will use it for easier coding, not for opposite.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net