Re: RFC: Nested enclosing returns

The main purpose of this RFC is *not* to improve the exception system of PHP but to improve the code logic/hierarchy. Using this like loop (for/foreach etc.) you can skip a lot of parent callers for a desired purpose by example. I agree with you in the sens were this can complicate significantly the debug/trace process, but IMO, there's more benefits than inconvenience. Also I agree with you too, were it can lead in a sort of "spaghetti code" feature (like Goto operator is...), but which language is not a bit "spaghetti" today? But my request is not to have a fully dynamic nested return, but a "controlled" dynamic nested return. I would not see this to be improved: return $something, $nesting_level; If I remember that feature has been removed in continue/break as of php 5.4, so this isn't that hard, right? :) Georges.L 2015-03-21 14:20 GMT+01:00 Benjamin Eberlei <kontakt@beberlei.de>: > > > On Sat, Mar 21, 2015 at 1:13 PM, Georges.L <contact@geolim4.com> wrote: > >> Hi php internals, >> >> After some long and deep research i finally decided to write my first RFC >> about a feature i'd be interested to be improved in the php core: *Nested >> enclosing returns* >> >> >> >> 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 thinks it'll being better with a scheme: >> >> >> >> >> function foo($foo = true) >> { >> if(!$foo) >> { >> return false, 3;// Please note the second return argument is the >> return nesting level >> } >> else >> { >> return true;// Default nested return argument is always equal to >> 1 (if not specified, current) >> } >> } >> >> function bar($foo = true) >> { >> foo($foo); >> // Some stuff that will never be executed if $foo == false and >> nested return argument = 2 >> echo 'Hi jon !'; >> } >> >> function baz($foo = true) >> { >> echo 'Hi bertie !'; >> foo($foo); >> // Some stuff that will never be executed if $foo == false and >> nested return argument = 3 >> echo 'Hi freddy !'; >> } >> >> >> baz(true); // Display: >> // Hi bertie ! >> // Hi jon ! >> // Hi freddy ! >> >> baz(false); // Display: >> // Hi bertie ! >> >> >> Benefits: >> -Wont break compatibility >> -May improve code interpretation speed due to part of code skipped by the >> nested return. >> -Allow "dynamic" return expressions. >> >> Inconveniences: >> -May complicate debug/backtrace >> > > Hi Georges, > > In my opinion this is a bad idea. > > With break/continue/goto the jumps are restricted to only one function > body to explicitly reduce the complexity in understanding them. > > With your proposal, as a user of a function I wouldn't know how deep a > function returns. This can easily lead to extremely unexpected behavior. > > This is why exceptions are better for jumps up the call-stack, because > they give the caller an explicit way of either accepting or catching the > jump. > >> >> >> Regards, >> Georges.L >> > >