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 <kont...@beberlei.de>:
>
>
> On Sat, Mar 21, 2015 at 1:13 PM, Georges.L <cont...@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
>>
>
>
