On 5/3/2016 11:23 PM, Ryan Pallas wrote: > Waiting for what example? There's been plenty of examples showing how > existing options, rewritten with |> are easier. If you disagree, that's an > opinion, other's agree. If people think its better, why not add it for > them? Like every other feature discussed on this list, nothing is forcing > you to use it. >
A real world example. :)
Nice to have does not necessarily mean that it should be added because
designing a language is a hard task and providing two or more ways to
achieve something is sometimes good and sometimes bad. I consider this
situation bad. That does not mean that I am right and you are wrong, it
is simply my opinion. I am also not saying that I would never use it if
it is there nor to I feel forced to use it if it is there. I just
believe that it is a bad syntactic sugar that encourages bad programming.
On 5/3/2016 11:23 PM, Ryan Pallas wrote:
> On Sat, Apr 30, 2016 at 4:00 AM, Thomas Punt <tp...@hotmail.co.uk> wrote:
>>
>>
>> $response = loadConfig()
>> |> buildDic($$)
>> |> getApp($$)
>> |> getRouter($app)
>> |> getDispatcher($$, $request)
>> |> dispatchBusinessLogic($$, $request, new Response())
>> |> renderResponse($$)
>> |> buildPsr7Response($$)
>> |> emit($$);
>>
>> Without the pipe operator, it could look like the following:
>>
>> $config = loadConfig();
>> $dic = buildDic(config);
>> $app = getApp($dic);
>> $router getRouter($app);
>> $dispatcher = getDispatcher($router, $request);
>> $businessResponse = dispatchBusinessLogic($dispatcher, $request, new
>> Response());
>> $renderedResponse = renderResponse($businessResponse);
>> $psr7Response = buildPsr7Response($renderedResponse);
>> $response = emit($psr7Response);
>>
>> That's a lot of unnecessary assignments, however, and the variable names
>> don't even provide any additional readability benefits because the function
>> names are already self-documenting.
>>
>>
> The first example, with |> is much easier to QUICKLY see what's happening,
> because all the function calls are aligned, so I can read quickly top to
> bottom knowing what's happening. The second requires much more cognitive
> interaction to understand what's going on. Sure you could reformat it to
> align all the =, now you have lots of white-space between your variables
> and what you're assigning to them... equally as bad in my book.
>
There are no /unnecessary assignments/ because those assignments happen
anyways even with the pipe operator. However, at least you have explicit
lifetime management.
But that is no my problem with that constructed example, it is the fact
that it assumes that all of those functions exist but there is no
software that defines such functions for those operations. Pretty much
all cool kids are using classes for this kind of stuff. But let us
assume we do it as proposed.
function getGlobals() {
// ...
}
function parseRequest($globals) {
// ...
}
function buildPsr7Request($request) {
// ...
}
function loadConfig() {
// ...
}
function buildDic($config) {
// ...
}
function getApp($dic) {
// ...
}
function getRouter($app) {
// ...
}
function getDispatcher($router, $request) {
// ...
}
function dispatchBusinessLogic($dispatcher, $request, $response) {
// ...
}
function renderResponse($businessResponse) {
// ...
}
function buildPsr7Response($renderedResponse) {
// ...
}
function emit($psr7Response) {
// ...
}
$request = getGlobals()
|> parseRequest($$)
|> buildPsr7Request($$);
$response = 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.
On 5/3/2016 11:23 PM, Ryan Pallas wrote:
> None, I don't write Symfony apps, however they wrote quite a few [1].
>
I was explicitly asking for userland Kernel and not for the base class
that Symfony provides.
On 5/3/2016 11:23 PM, Ryan Pallas wrote:
>> A rather extreme example of such a /most outer/ but you know how it is
>> with constructed examples:
>>
>> http://www.yegor256.com/2014/10/03/di-containers-are-evil.html#the-right-way
>
> GROSS. This would not be allowed any where I do code reviews.
>
What would be your answer if the author asks /why?/
On 5/3/2016 11:23 PM, Ryan Pallas wrote:
> You didn't address the fact that your "solution" makes it much harder to
> modify the steps in place.
>
> $ret = getConfig()
> |> buildApp($$)
> |> buildRouter($$)
> |> parseResponse($$);
>
> Shoot, I forgot to build Dispatcher; Let me add that
>
> $ret = getConfig()
> |> buildApp($$)
> |> buildRouter($$)
> + |> buildDispatcher($$)
> |> parseResponse($$);
>
> Such a minimal change. Lets try yours:
>
> final class ResponseBuilder {
> private $config;
> private $app;
> private $router;
> private $response;
>
> private function loadConfig() {}
>
> private function buildApp() {
> $this->app = new App($this->config);
> }
>
> private function buildRouter() {
> $this->router = new Router($this->app);
> }
>
> private function parseResponse() {
> $this->response = new Response($this->router);
> }
>
> public function build() {
> $this->loadConfig();
> $this->buildApp();
> $this->buildRouter();
> $this->parseResponse();
>
> return $this->response;
> }
> }
>
> Shoot, I forgot dispatcher; let me add that
>
> final class ResponseBuilder {
> private $config;
> private $app;
> private $router;
> + private $dispatcher;
> private $response;
>
> private function loadConfig() {}
>
> private function buildApp() {
> $this->app = new App($this->config);
> }
>
> private function buildRouter() {
> $this->router = new Router($this->app);
> }
>
> + private function buildDispatcher() {
> + $this->dispatcher = new Dispatcher($this->router);
> + }
> +
> private function parseResponse() {
> - $this->response = new Response($this->router);
> + $this->response = new Response($this->dispatcher);
> }
>
> public function build() {
> $this->loadConfig();
> $this->buildApp();
> $this->buildRouter();
> + $this->buildDispatcher();
> $this->parseResponse();
>
> return $this->response;
> }
> }
>
> Whoa that's significantly more changes, and therefore significantly more
> chances to make a typo!
>
At least the complexity is not completely hidden behind some arbitrary
procedural function call. You assume that the procedural function that
you are introducing already exists and returns the correct thingy that
continues the chain in exactly the order you want it too. Those are a
lot of assumptions considering the fact that the pipe operator is meant
for combining arbitrary libraries.
Sorry, not convinced but a real world example might change that. ;)
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
