On 5/3/2016 8:57 PM, Sara Golemon wrote: > Ooops, missed a negation when I typed it out. > > "Pretending that poorly designed libraries DON'T exist is naîve." >
I am not pretending that they do not exist, quite the contrary, I
explicitly stated that they exist and that I fear that this syntactic
sugar yields more of them in the future.
On 5/3/2016 8:57 PM, Sara Golemon wrote:
> As I've said already. Yes, intermediate variables do address this
> style of coding. Yes, this proposal is syntactic sugar.
>
> Intermediate variables also add cognitive overhead of their own in
> cataloging all the various intermediates used in a large function. By
> removing the explicit intermediate variables and replacing them with
> unnamed temporaries, the code becomes easier to read because there's
> less unnecessary assignments cluttering up the space.
>
Still waiting for a real life example that illustrates exactly that. All
examples and code I have seen so far is either extremely constructed
(the request-application-response thingy that is now part of the RFC) or
can be trivially rewritten to be super expressive and readable (the
original from the RFC and most in this thread).
$request = getGlobals()
|> parseRequest($$)
|> buildPsr7Request($$);
Ask, don't tell!
final class RequestBuilder {
public static function fromGlobals() {
return new static($_GLOBALS);
}
public function buildPsr7Request() {
$parsed_request = $this->parseRequest();
return new Psr7Request($parsed_request);
}
}
$request = RequestBuilder::fromGlobals()->buildPsr7Request();
$response = loadConfig()
|> buildDic($$)
|> getApp($$)
|> getRouter($app)
|> getDispatcher($$, $request)
|> dispatchBusinessLogic($$, $request, new Response())
|> renderResponse($$)
|> buildPsr7Response($$)
|> emit($$);
Ask, don't tell!
final class ResponseBuilder {
public static function fromGlobals() {
return new static($_GLOBALS);
}
public function build() {
$this->loadConfig();
$this->buildDic();
$this->buildApp();
$this->buildRouter();
$this->buildDispatcher();
$this->dispatchBusinessLogic();
$this->parseResponse();
return $this->response;
}
}
$response = ResponseBuilder::fromGlobals()->build();
The third is exactly the same ...
Now my favorite:
$ret =
array_merge(
$ret,
getFileArg(
array_map(
function ($x) use ($arg) { return $arg . '/' . $x; },
array_filter(
scandir($arg),
function ($x) { return $x !== '.' && $x !== '..'); }
)
)
)
);
I already rewrote it in another message but once more with the most
relevant parts of my original message:
array_filter with O(n)
array_map with O(n)
array_merge with O(∑ array_i, i != 1) and in our case O(n) where n
equals the total count of elements in $files/$$.
In my universe `getFileArg` (note the absence of a plural form) would
operate on a single path and not on an array of paths:
foreach (new DirectoryIterator($arg) as $path) {
if ($path->isDot() === false) {
$ret[] = getFileArg($arg . DIRECTORY_SEPARATOR . $path);
}
}
Ocramius mentioned that the pipe operator would be super useful in async
libraries and stuff but I am lacking real world examples here that
illustrate how this new operator would make those experimental stuff
benefit from it. Especially benefit besides scalar objects.
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
