Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:92982 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 17525 invoked from network); 30 Apr 2016 13:52:44 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 30 Apr 2016 13:52:44 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.214 mail4-2.serversure.net Linux 2.6 Received: from [217.147.176.214] ([217.147.176.214:55275] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 25/68-58459-8A8B4275 for ; Sat, 30 Apr 2016 09:52:41 -0400 Received: (qmail 20682 invoked by uid 89); 30 Apr 2016 13:52:37 -0000 Received: by simscan 1.3.1 ppid: 20675, pid: 20679, t: 0.1070s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.7?) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 30 Apr 2016 13:52:37 -0000 To: internals@lists.php.net References: Message-ID: <5724B8A4.4010304@lsces.co.uk> Date: Sat, 30 Apr 2016 14:52:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Pipe Operator From: lester@lsces.co.uk (Lester Caine) On 29/04/16 20:58, Sara Golemon wrote: > This is one of my favorites out of HackLang. It's pure syntactic > sugar, but it goes a long way towards improving readability. > https://wiki.php.net/rfc/pipe-operator I can see the attraction, but question it's usability in real time code. It assumes everything has a single linear flow? Once one has branches handing different results from the various stages it's usability looks questionable. While one may well be able to break things down with exceptions handling all of the invalid returns, if one needs to 'break the flow' to put in an alternate path then what is supposedly a simple sequence of steps becomes difficult to rework to allow for the change? Exceptions should be reserved for out of the ordinary events, not changes in work flow because different paths are equally valid? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk