Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:93050 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 26091 invoked from network); 3 May 2016 19:28:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 May 2016 19:28:51 -0000 Authentication-Results: pb1.pair.com header.from=php@fleshgrinder.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=php@fleshgrinder.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.86 cause and error) X-PHP-List-Original-Sender: php@fleshgrinder.com X-Host-Fingerprint: 77.244.243.86 mx105.easyname.com Received: from [77.244.243.86] ([77.244.243.86:60631] helo=mx207.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DD/C7-03860-2FBF8275 for ; Tue, 03 May 2016 15:28:51 -0400 Received: from cable-81-173-133-226.netcologne.de ([81.173.133.226] helo=[192.168.178.20]) by mx.easyname.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1axfzy-0006Tv-Qt; Tue, 03 May 2016 19:28:47 +0000 Reply-To: internals@lists.php.net References: <4fc01507-3d07-2309-a4e4-4cad7325249b@gmail.com> <39071a01-a42c-0952-b3a8-b4769c79b56b@fleshgrinder.com> <0ac3be89-6fb4-610a-ef89-0928f264f96c@fleshgrinder.com> To: Sara Golemon , PHP internals Cc: Terry Cullen , Stephen Coakley Message-ID: <71379db5-b7b8-78b3-ada5-eee34e6e22d6@fleshgrinder.com> Date: Tue, 3 May 2016 21:28:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hA9JhQhRTTHe981gwIex30L8RxFIJv5UT" X-ACL-Warn: X-DNSBL-BARRACUDACENTRAL Subject: Re: [PHP-DEV] [RFC] Pipe Operator From: php@fleshgrinder.com (Fleshgrinder) --hA9JhQhRTTHe981gwIex30L8RxFIJv5UT Content-Type: multipart/mixed; boundary="FnDWjhdJSBHX2hG8RakBJiu6MkgwSnI4x" From: Fleshgrinder Reply-To: internals@lists.php.net To: Sara Golemon , PHP internals Cc: Terry Cullen , Stephen Coakley Message-ID: <71379db5-b7b8-78b3-ada5-eee34e6e22d6@fleshgrinder.com> Subject: Re: [PHP-DEV] [RFC] Pipe Operator References: <4fc01507-3d07-2309-a4e4-4cad7325249b@gmail.com> <39071a01-a42c-0952-b3a8-b4769c79b56b@fleshgrinder.com> <0ac3be89-6fb4-610a-ef89-0928f264f96c@fleshgrinder.com> In-Reply-To: --FnDWjhdJSBHX2hG8RakBJiu6MkgwSnI4x Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/3/2016 8:57 PM, Sara Golemon wrote: > Ooops, missed a negation when I typed it out. >=20 > "Pretending that poorly designed libraries DON'T exist is na=C3=AEve." >=20 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. >=20 > 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. >=20 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 =3D getGlobals() |> parseRequest($$) |> buildPsr7Request($$); Ask, don't tell! final class RequestBuilder { public static function fromGlobals() { return new static($_GLOBALS); } public function buildPsr7Request() { $parsed_request =3D $this->parseRequest(); return new Psr7Request($parsed_request); } } $request =3D RequestBuilder::fromGlobals()->buildPsr7Request(); $response =3D 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 =3D ResponseBuilder::fromGlobals()->build(); The third is exactly the same ... Now my favorite: $ret =3D array_merge( $ret, getFileArg( array_map( function ($x) use ($arg) { return $arg . '/' . $x; }, array_filter( scandir($arg), function ($x) { return $x !=3D=3D '.' && $x !=3D=3D '..'); } ) ) ) ); 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(=E2=88=91 array_i, i !=3D 1) and in our case O(n) wher= e 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() =3D=3D=3D false) { $ret[] =3D 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. --=20 Richard "Fleshgrinder" Fussenegger --FnDWjhdJSBHX2hG8RakBJiu6MkgwSnI4x-- --hA9JhQhRTTHe981gwIex30L8RxFIJv5UT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXKPvoAAoJEOKkKcqFPVVr41wP/jXuyW/U+m90WnXmAIuf5R8O QQza3hymyWOTmFSPLsY1mx+T3GYPyhM2ezlhd4SgGQphzdSrCnCL5cmS9u7nM7RI lZIFSrNV3wRrcaGpTLtzcEg9yhdDBFMhpP5oMmjliIT8sOTF9x24+lOkvgwPF7ai xuuhRes3mkbOinj8sqawFf5yiaTDOGtS/d+6TErh4X7chZ3eq7+3bKXIVL2k7LZH 1aJybv4I23cNe2I+mNHBuRbc1mLFb/TmvtX6FDj09GIlC7AcujqzLBlvQAtsp6CQ 9LiVQNAq3oOy3ffzlV5LaiND77eW79mQwac0VTBgd42qlMYXlfKsC9GtbO6PT6G0 /eodmhZzcA9l4xyXx0/Dt57ps2OwOYkWp4CO4ZTBtW0Wz8jSPidpOSiSneXQIoyh lqqA6aYKeyhHYQ/IsokJe877w0ctYziXbNN8M4mUztuk/XgX5rfDboWWnUdCRRif 8FNaNKVJImcs8Gwx27C2PMoaOLJ0ZvL/MYkTytsvXIJTPtbSN92Ph12gAxQws4pU /rxX7auY7OCMGmqR0sUguM6BnF/yjBTffRisIRCnO9ucUvHvaj3kWXGduBY0Ikww VzGh2wDvxbriIlYWakO5mzBRhdO5XAyrU2/kYZdPEuayp6PRg7WzkkHnhTjVZKKY H5zrD6/OVxmc2acULw0E =ZK/3 -----END PGP SIGNATURE----- --hA9JhQhRTTHe981gwIex30L8RxFIJv5UT--