Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:85404 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 57271 invoked from network); 22 Mar 2015 09:41:07 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Mar 2015 09:41:07 -0000 Authentication-Results: pb1.pair.com smtp.mail=rowan.collins@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=rowan.collins@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.177 as permitted sender) X-PHP-List-Original-Sender: rowan.collins@gmail.com X-Host-Fingerprint: 209.85.212.177 mail-wi0-f177.google.com Received: from [209.85.212.177] ([209.85.212.177:37670] helo=mail-wi0-f177.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6D/87-00828-13E8E055 for ; Sun, 22 Mar 2015 04:41:07 -0500 Received: by wixw10 with SMTP id w10so31409999wix.0 for ; Sun, 22 Mar 2015 02:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type:subject:from:date:to:cc :message-id; bh=RMZAt5TCbRg3aCBvhYZhj43uaGD7pR9zNefVlLWApmw=; b=hxaTuuZ06mEUOw80LZhcYwkFoyko95LuRlmAd+1RMR4FP8G2AAS8wyONdJG8ArwkYp al7nrsg0JejFyEgVk55dWhMVbJ2GwpcFFesnvat76iBg7TGTmC2aQlKAgXYoi6OGPBdp lYn8NXazqvaG4I07M+Fi0lAZCUvf4DJuzFo3gKj1g05xqIF0gbMlZ4vMQ75GhGzshZwt FPIWiTu0Km22/nHAe1kx+wCSGdStaQEj6s2Aa+WFmWZvvypqCdSRzIKLIuSvscY+pbw3 BEQB90XJSWMdAKNDnZZyk3yM2i7cxXGUGXdpaf91OrPMGO44+W+gK5MWXeg2iuItTtde NeyA== X-Received: by 10.194.208.229 with SMTP id mh5mr155022230wjc.108.1427017262728; Sun, 22 Mar 2015 02:41:02 -0700 (PDT) Received: from [192.168.0.2] (cpc68956-brig15-2-0-cust215.3-3.cable.virginm.net. [82.6.24.216]) by mx.google.com with ESMTPSA id gt4sm5829134wib.21.2015.03.22.02.41.01 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Mar 2015 02:41:01 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: References: <3136D99B-EA3D-4AF1-9B20-C13DF55E3A53@zort.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Date: Sun, 22 Mar 2015 09:39:57 +0000 To: "Georges.L" ,John Bafford CC: Benjamin Eberlei ,PHP Internals Message-ID: Subject: Re: [PHP-DEV] RFC: Nested enclosing returns From: rowan.collins@gmail.com (Rowan Collins) On 21 March 2015 17:55:32 GMT, "Georges.L" wrote: >To be honest I had not thought about the bad side of this use, i guess >it >could be possible to not return upper than a try/catch block (then >return a >fatal error if our code is trying to returns upper than a try/catch >block). > >Now the practical example: > >// Code i have the hand on >function main() >{ > foo('bar'); > echo "I'm an angel !"; >} > >function bar() >{ > echo "I'm not Evil"; >} > >//Code i don't have the hand on (like a MVC core) >function foo($thing) >{ > // > make_love_dont_war(); > call_user_func($thing); > > //Do some stuff i don't want to execute > echo 'evil'; >} > >function make_love_dont_war() >{ > echo 'Make love, dont war.'; >} > >You get it ? Not really, no. In this example, the code you want to skip happens to be all the code after executing the callback, but what if there was some essential cleanup there, or the "evil" line was before the callback, not after? In general, a function should be a reusable, self-contained unit of code, and as such shouldn't want to know about where it was called from. But in order to know how many levels to force to return, you need to know how deeply nested you are, and the expected return type of the function you're jumping out of, as well as which code you're bypassing by doing so. If someone reuses the function, or refactors the calling code, some very confusing bugs will result. Rather than "jump N levels up the call stack", what you maybe want is "jump up to somewhere labelled X". This is sort of what exceptions do - they jump up the stack until they find somewhere expecting to handle that condition. The function throwing the exception doesn't know where it will be caught, so is not fragile to reuse or refactoring. However, using exceptions for anything other than error handling is generally frowned upon, because they can lead to hard to follow logic which would be better off refactored in plain procedural/OO style. In your example, it's up to the maintainers of the foo() function (e.g. framework) to make the "evil" optional, by passing in some additional setting, or allowing the callback to return a special value, or just splitting the work in such a way that you can access the desired functionality without calling foo() at all. If it's open source, you could submit a patch, or, worst case, maintain a fork. Regards, -- Rowan Collins [IMSoP]