Re: Design by Contract

From: 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 >>> >> >> >

« previous php.internals (#82363) next »