Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:93287 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 8316 invoked from network); 12 May 2016 18:52:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 May 2016 18:52:24 -0000 Authentication-Results: pb1.pair.com header.from=francois@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=francois@php.net; spf=unknown; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender) X-PHP-List-Original-Sender: francois@php.net X-Host-Fingerprint: 212.27.42.2 smtp2-g21.free.fr Received: from [212.27.42.2] ([212.27.42.2:38875] helo=smtp2-g21.free.fr) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F8/84-28272-6E0D4375 for ; Thu, 12 May 2016 14:52:23 -0400 Received: from [127.0.0.1] (unknown [82.240.16.115]) (Authenticated sender: flaupretre@free.fr) by smtp2-g21.free.fr (Postfix) with ESMTPSA id AF96C2003DC; Thu, 12 May 2016 18:42:24 +0200 (CEST) To: Sara Golemon , Zeev Suraski References: <452ddb93-1f47-1d0f-4f24-bedbff506b27@gmail.com> <98.61.11104.A1D41375@pb1.pair.com> <7c94ca37-e188-dd2b-a66f-bb63bf03041a@gmail.com> <1463008795.1856219.605250569.74618FC4@webmail.messagingengine.com> <92E7F8A8-0845-48A7-91B1-9554C5F66C9D@zend.com> Cc: Quim Calpe , "davey@php.net" , Larry Garfield , "internals@lists.php.net" Message-ID: <879feadf-c04e-c0de-826b-110b3eb4e22f@php.net> Date: Thu, 12 May 2016 20:52:03 +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: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 160512-1, 12/05/2016), Outbound message X-Antivirus-Status: Clean Subject: Re: [PHP-DEV] [RFC] Pipe Operator From: francois@php.net (=?UTF-8?Q?Fran=c3=a7ois_Laupretre?=) Hi Sara, Le 12/05/2016 à 19:02, Sara Golemon a écrit : > On Thu, May 12, 2016 at 5:48 AM, Zeev Suraski wrote: >> Whether it's $$ or !# or $0 or any other random symbol doesn't really matter. >> > Agreed. > >> Here we have a completely optional syntactic sugar, >> that's not nearly as widely useful as OOP or namespaces. >> > Very few things will be as widely useful as OOP or namespaces, so that > comparison is a bit of a red herring. This construct is useful > anywhere function call nesting pushes you past a readability > threshold. That's not as ubiquitous as OOP as a whole, but it's > pretty widespread. As widespread as fluent call chaining, in fact. > >> The question is whether the added complexity of a new operator, >> a new symbol and the new semantics around them both are >> worth the benefit of introducing them. >> > Agreed. There's a cost to every new token and parser rule on the > compiler side, and there's a cognitive overhead on the script > maintainer side as well. It seems we only disagree in the flexibility > provided by better syntax and the ease of using google, > stack-overflow, and php.net/manual. > >> IMHO it's not. >> > And I'll expect you to vote accordingly. No hard feelings. :) > > -Sara > Currently, the proposal accepts any expression between '|>' operators, which requires the '$$' placeholder (as '|> $$ + 2 |>' would be valid). If we restrict usage to function calls, we can quite easily get rid of the $$ by associating to each function the position where the lhs must be inserted when used as a 'piped function call'. This position would be 0 (first arg) for most existing functions and 2, for instance, for str_replace(). Getting rid of the $$ would resolve most issues about parameter order in the existing library, which is probably the biggest PHP sadness. My question, before I write a detailed proposal for this, is : do you want to keep the possiblility to use *any* expression between pipe operators, or would it be acceptable to restrict this to function calls? Note that it would also disambiguate 'piped assignments' like '|> $var |>' (assigning to an intermediate or final variable). Regards François