Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:85403 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 54486 invoked from network); 22 Mar 2015 09:06:48 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Mar 2015 09:06:48 -0000 Authentication-Results: pb1.pair.com smtp.mail=php@bof.de; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=php@bof.de; sender-id=pass Received-SPF: pass (pb1.pair.com: domain bof.de designates 80.242.145.70 as permitted sender) X-PHP-List-Original-Sender: php@bof.de X-Host-Fingerprint: 80.242.145.70 mars.intermailgate.com Received: from [80.242.145.70] ([80.242.145.70:36184] helo=mars.intermailgate.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CA/27-00828-7268E055 for ; Sun, 22 Mar 2015 04:06:47 -0500 Received: (qmail 4315 invoked by uid 1009); 22 Mar 2015 10:06:44 +0100 Received: from 209.85.216.179 by mars (envelope-from , uid 89) with qmail-scanner-1.25-st-qms (clamdscan: 0.96.2/20220. spamassassin: 3.3.1. perlscan: 1.25-st-qms. Clear:RC:1(209.85.216.179):. Processed in 0.271095 secs); 22 Mar 2015 09:06:44 -0000 X-Antivirus-MYDOMAIN-Mail-From: php@bof.de via mars X-Antivirus-MYDOMAIN: 1.25-st-qms (Clear:RC:1(209.85.216.179):. Processed in 0.271095 secs Process 4259) Received: from mail-qc0-f179.google.com (gmail@bof.de@209.85.216.179) by mars.intermailgate.com with RC4-SHA encrypted SMTP; 22 Mar 2015 10:06:44 +0100 Received: by qcto4 with SMTP id o4so124649313qct.3 for ; Sun, 22 Mar 2015 02:06:43 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.235.20 with SMTP id g20mr12865881qhc.32.1427015203167; Sun, 22 Mar 2015 02:06:43 -0700 (PDT) Received: by 10.140.82.198 with HTTP; Sun, 22 Mar 2015 02:06:43 -0700 (PDT) Received: by 10.140.82.198 with HTTP; Sun, 22 Mar 2015 02:06:43 -0700 (PDT) In-Reply-To: References: Date: Sun, 22 Mar 2015 10:06:43 +0100 Message-ID: To: "Georges.L" Cc: internals Content-Type: multipart/alternative; boundary=001a1135cffc4624960511dcde63 Subject: Re: [PHP-DEV] RFC: Nested enclosing returns From: php@bof.de (Patrick Schaaf) --001a1135cffc4624960511dcde63 Content-Type: text/plain; charset=UTF-8 Am 21.03.2015 14:15 schrieb "Georges.L" : > > The main purpose, as the title say, is to have the possibility to nest > multiple return like we can do currently with break/continue. I think that is a complete nonstarter. Functions are reusable building blocks, designed to be called from various places that the function author should not be concerned with. break/continue can always be analyzed at the single function level, with semantics unambiguously given by the local nesting level within the function. On the other hand, functions being called from various places means the nesting distance between a given point in the outer program, and the function itself, is completely arbitrary for different calls. In some places in our codebase we have logging functions that try to show "logically useful" debug_backtraces, by leaving out a number of "lowest" levels of the stack. Starting down that road soon required us to introduce "$up = 2" parameters to the inner logging functions, so that different call pathes could impose how much to leave out (think some convenience wrappers). This is a very brittle thing to do. Okay for debug backtrace logging, because at worst it shows some unneccessary level or leaves out some. But totally unmanageable when it affects really control flow. I know exactly one language that provides similar stuff - TCL with its uplevel and upvar constructs - and anybody who had to wrap their heads around code using that, nifty as it can be, will know the cognitive strain involved... Patrick --001a1135cffc4624960511dcde63--