Re: Design by Contract
| From: | Dmitry Stogov | Date: | Tue, 10 Feb 2015 10:21:15 +0000 |
| Subject: | Re: Design by Contract | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-82363@lists.php.net to get a copy of this message | ||
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
>>>
>>
>>
>