Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85369
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain geolim4.com designates 212.129.18.216 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEPJdunjGoA9HJsvBgouitnsyY0_f7XNZ=Ey98FyVwY0R51rMw@mail.gmail.com>
References: <CACjyb+xrqDhyBNjUBhedFH6faaPKamV7o2j1ChUEoVodgo-bnw@mail.gmail.com>
 <CAEPJdunjGoA9HJsvBgouitnsyY0_f7XNZ=Ey98FyVwY0R51rMw@mail.gmail.com>
Date: Sat, 21 Mar 2015 15:17:46 +0100
Message-ID: <CACjyb+xoknqifsy7D3MDUC4QDmVphLFfoTpa0vVKm=4F2DqONg@mail.gmail.com>
To: Benjamin Eberlei <kontakt@beberlei.de>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114412bca0ae780511cd1a87
Subject: Re: [PHP-DEV] RFC: Nested enclosing returns
From: contact@geolim4.com ("Georges.L")

--001a114412bca0ae780511cd1a87
Content-Type: text/plain; charset=UTF-8

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
>>
>
>

--001a114412bca0ae780511cd1a87--