Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:93021 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 41420 invoked from network); 1 May 2016 15:52:04 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 May 2016 15:52:04 -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:33421] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1A/D3-03860-12626275 for ; Sun, 01 May 2016 11:52:01 -0400 Received: (qmail 6922 invoked by uid 89); 1 May 2016 15:51:58 -0000 Received: by simscan 1.3.1 ppid: 6915, pid: 6918, t: 0.1024s 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; 1 May 2016 15:51:58 -0000 To: internals@lists.php.net References: <8ea990da-1fe7-256c-4e08-0b30715c8e8a@gmail.com> Message-ID: <5726261D.3020506@lsces.co.uk> Date: Sun, 1 May 2016 16:51:57 +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 01/05/16 15:39, Dan Ackroyd wrote: > Marco wrote: >> > Relevant: https://youtu.be/UvD1VjRvGIk > I could imagine how having inline branches could be a useful thing for > functional programming, for various scenarios, including being able to > 'inline' error handling, to be nearer the source of errors. However > this RFC does not propose that. A little off topic, but in line with the debate in general on performance. The interesting bit relating to error handling was the 'lack of strings'. But the idea of just building a longer and longer list of error codes and then having to manage translations as well. One of the major advantages of adding a database to the production system is that lists like this can be generically managed, and selecting a translated version is simply a matter of a flag on the database. But code wise inside PHP much of what is essentially text can be managed as simple integer values. Add the same message process to the good paths as well and a lot of string activity can be relegated to the display rendering stage. -- Lester Caine - G8HFL -----------------------------Marco wrote:Marco wrote:Marco wrote:Marco Marco wrote: > Relevant: https://youtu.be/UvD1VjRvGIk I could imagine how having inline branches could be a useful thing for functional programming, for various scenarios, including being able to 'inline' error handling, to be nearer the source of errors. However this RFC does not propose that.Marco wrote: > Relevant: https://youtu.be/UvD1VjRvGIk I could imagine how having inline branches could be a useful thing for functional programming, for various scenarios, including being able to 'inline' error handling, to be nearer the source of errors. However this RFC does not propose that.wrote: > Relevant: https://youtu.be/UvD1VjRvGIk I could imagine how having inline branches could be a useful thing for functional programming, for various scenarios, including being able to 'inline' error handling, to be nearer the source of errors. However this RFC does not propose that. > Relevant: https://youtu.be/UvD1VjRvGIk I could imagine how having inline branches could be a useful thing for functional programming, for various scenarios, including being able to 'inline' error handling, to be nearer the source of errors. However this RFC does not propose that. > Relevant: https://youtu.be/UvD1VjRvGIk I could imagine how having inline branches could be a useful thing for functional programming, for various scenarios, including being able to 'inline' error handling, to be nearer the source of errors. However this RFC does not propose that. > Relevant: https://youtu.be/UvD1VjRvGIk I could imagine how having inline branches could be a useful thing for functional programming, for various scenarios, including being able to 'inline' error handling, to be nearer the source of errors. However this RFC does not propose that. 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