Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82363
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAL=_i_mFfi08GUHZVSQana976rYUVp9zzefB980jPptsnGqtKA@mail.gmail.com>
References: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com>
	<54D7ED22.3080001@gmail.com>
	<CA+9eiLvn7BzfG5N+5Oca8pVO1OTzN9=jWof6NrVDfxvvu-XqPA@mail.gmail.com>
	<CAL=_i_m78Zo5euReKsvFfrLknFq7KEzoNnrrBefC987u+=+yHQ@mail.gmail.com>
	<CA+9eiLuUFiKwOR-BqQEmkQirpAMxgb0GE70Zz7h4WDsd1Me8FQ@mail.gmail.com>
	<CAGa2bXYDvdvRLiOpDk8EnvE00JE4x47SXB9fET4uO2Er_F6s_w@mail.gmail.com>
	<CAL=_i_=mGc_0u0YDCQ7Jiqn_ggyJmQSd_mk_snf7ArDpDXO53A@mail.gmail.com>
	<CA+9eiLur0DVGBNkzFkiTj3POL5B9H0D8=5wE-wuwN2O-FQZNyg@mail.gmail.com>
	<CAL=_i_m=XDKtc2iCSjoquaHkmX862gyMweKS5Xw4AS--oLj19w@mail.gmail.com>
	<CA+9eiLsX=mOOgXmNBKD1L6WKx2=Vy81mThaKa1XCjjAw6R=2vA@mail.gmail.com>
	<CAGa2bXYYp0WQmnTnbsHXzc8XGG0PxOVHu7XvwiMCSJiUWoKeCg@mail.gmail.com>
	<CA+9eiLtj79MevMVg1cBSzGvfcdH=jszWym1Bf50zRsQ+94jp5w@mail.gmail.com>
	<CAGa2bXY6OO2svdcguHLEYxQ_XUHjssBjgwJ_Had+JPjFzbZ80g@mail.gmail.com>
	<CAJ26g5QT2545yKEEHD3hho_FAVzF+Vs5qsExtZqDO+RqDTZUjg@mail.gmail.com>
	<CA+9eiLu5TY=3zv8Zx+2q83pf+vviNc326S=WXXOGuwgVt=asUw@mail.gmail.com>
	<CAGa2bXb0w=SDmphk2O2WF+RcbtYhx=pMjddE5kyOBBLBSpVBeg@mail.gmail.com>
	<CAL=_i_nrrmS08tYJ==0Pe0B34Ji1ykMbE9anbDpU2KN-vBbapg@mail.gmail.com>
	<CAGa2bXaPLA0hAkxseUsAd+s+Hq60pia7t8X4DusND8r2fiFwYQ@mail.gmail.com>
	<CAL=_i_=gg+WWU+d1K-A=rdf+f2=+mBGDVC4UKqmBOsiNMMBj1g@mail.gmail.com>
	<CA+9eiLuUqbO-PG7Ur36r2ekoConurvJ2ZBr6031BYndL7+GE0g@mail.gmail.com>
	<CA+9eiLuJpDrPzSkyYm=+FSEJWVG4btvTWVejDt2V54yPRofFWA@mail.gmail.com>
	<CAJ26g5RQL7BOaXtVmrDnQSPvsyZdrCJOUX9_N9Rwezm_D1q__w@mail.gmail.com>
	<CA+9eiLsqJ5C13_na-E1r+Tc-m84jRNYHgUgyu_Jk3KgYiR9JfQ@mail.gmail.com>
	<CAL=_i_mFfi08GUHZVSQana976rYUVp9zzefB980jPptsnGqtKA@mail.gmail.com>
Date: Tue, 10 Feb 2015 14:21:15 +0400
Message-ID: <CA+9eiLsfBMXv+fGQLKfF6svshuwiL1yfuhXD=BpB5dSA8wr4zg@mail.gmail.com>
To: Joe Watkins <pthreads@pthreads.org>
Cc: Patrick Schaaf <php@bof.de>, internals <internals@lists.php.net>, 
	Yasuo Ohgaki <yohgaki@ohgaki.net>
Content-Type: multipart/alternative; boundary=001a11c3ea3c397d1c050eb93f82
Subject: Re: [PHP-DEV] Design by Contract
From: dmitry@zend.com (Dmitry Stogov)

--001a11c3ea3c397d1c050eb93f82
Content-Type: text/plain; charset=UTF-8

D uses block syntax:

ensure(ret) {
}

In this case, passing 'ret' as a 'parameter' looks more or less natural.

In our case, two sets of brackets looks weird.
Predefined variable or constant looks better.
A agree, __RETURN__ is longer than $ret, but it also won't conflict with
other variables.
I don't see a perfect solution yet.

may be something similar to Smaltalk block syntax: return(<var-name>,
<expression> [, <optional-message>])

function add($a, $b)
    return($ret, $ret > 0)
{
    return $a + $b;
}

Thanks. Dmitry.

On Tue, Feb 10, 2015 at 1:03 PM, Joe Watkins <pthreads@pthreads.org> wrote:

> The solution D uses is allowing the programmer to declare the name of the
> return value like, we could do something like:
>
> public function method()
>     return ($result) ($result <= 10 && $result >= 0) {
>     return 5;
> }
>
> If you didn't need the result, were working with a scope variable, or
> maybe even a param taken by reference:
>
> public function method()
>    return ($expr) {
>    /* ... */
> }
>
> I'm not keen on __CONSTANTS__, it's long, and if you have the choice to
> name the variable you have the option of making the expression ...
> expressive ...
>
> Cheers
> Joe
>
> On Tue, Feb 10, 2015 at 9:48 AM, Dmitry Stogov <dmitry@zend.com> wrote:
>
>> I think __RETURN__ is better than $ret.
>>
>> Dmitry.
>>
>> On Tue, Feb 10, 2015 at 12:43 PM, Patrick Schaaf <php@bof.de> wrote:
>>
>>> Am 10.02.2015 09:29 schrieb "Dmitry Stogov" <dmitry@zend.com>:
>>> >
>>> > I cnahged $> into $ret, because $> just won't work. Some better
>>> solution is welcome.
>>>
>>> Also think $> would be awful. Don't like $ret either. What about a magic
>>> constant __RETURN__ or __RESULT__? This would stand out very well when
>>> glancing at the expression, would fit in with naming of other magic
>>> constants, and might even be made to work in finally blocks, where the same
>>> need for access to the returned value exists.
>>>
>>> best regards
>>>   Patrick
>>>
>>
>>
>

--001a11c3ea3c397d1c050eb93f82--