Re: Design by Contract

yes. this may work. probably better to put it after extends and implements. Dmitry. On Mon, Feb 9, 2015 at 2:19 PM, Joe Watkins <pthreads@pthreads.org> wrote: > Could this be described as a requirement of the class ? > > class Mine > require(invariant-expr) > extends Something > implements Someface { > > public function method($param) : return > require(input-expr), > return(output-expr) { > > } > } > > To avoid invariant keyword maybe. > > Cheers > Joe > > On Mon, Feb 9, 2015 at 11:05 AM, Dmitry Stogov <dmitry@zend.com> wrote: > >> invariant is for classes only. It should be called before and/or after >> each method to check object consistency. >> >> syntax with expressions may work if we put constraints before the >> function body . >> >> function foo($a int): int >> require(expr1) >> require(expr2, msg) >> return(expr3) >> { >> } >> >> Yasuo, I would suggest to describe both syntax options. >> >> Thanks. Dmitry. >> >> On Mon, Feb 9, 2015 at 1:46 PM, Joe Watkins <pthreads@pthreads.org> >> wrote: >> >>> Morning Yasuo, >>> >>> Can you explain what invariant is for ? >>> >>> I prefer a list of contracts with a single expression, over blocks >>> of expressions in one contract. >>> An IDE can just as easy generate a block of code or set of >>> contracts, so it's really just a matter of how complex it makes the >>> implementation if you allow any block of code in the contract. I think it >>> does make it unnecessarily complicated to implement, I can be wrong. >>> >>> If there is going to be two rfc's, I will vote no on the annotations >>> based one, I'd rather no time was wasted on even writing it; Before you >>> convince anyone that DBC is a good idea you have to convince them >>> annotations is a good idea, many have tried and failed. >>> >>> Cheers >>> Joe >>> >>> On Mon, Feb 9, 2015 at 10:34 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> >>> wrote: >>> >>>> Hi Dmitry and Joe, >>>> >>>> On Mon, Feb 9, 2015 at 6:01 PM, Dmitry Stogov <dmitry@zend.com> wrote: >>>> >>>>> Usage of "return" is a good idea. >>>>> The more heads the better result :) >>>>> >>>> >>>> Less additional reserved word :) >>>> So I'll use "require" and "return" for D like RFC. >>>> We haven't talk much about invariants. I'll write my idea. >>>> >>>> Current RFC is large enough already, I'll prepare new one. >>>> We may decide what to do with 2 RFCs. >>>> >>>> We have choices for with block or without block. I prefer with block >>>> version, since >>>> assert expression could be messy. With block, IDE may do it's jobs. >>>> i.e. Hide blocks. >>>> >>>> ============================================== >>>> Function/Method >>>> >>>> [With block] >>>> function foo() >>>> require { >>>> assert(assert-expr, 'msg'); >>>> assert(assert-expr, 'msg'); >>>> assert(assert-expr, 'msg'); >>>> } >>>> return { >>>> assert(assert-expr, 'msg'); >>>> assert(assert-expr, 'msg'); >>>> assert(assert-expr, 'msg'); >>>> } >>>> invariant { >>>> assert(assert-expr, 'msg'); >>>> assert(assert-expr, 'msg'); >>>> assert(assert-expr, 'msg'); >>>> } >>>> { >>>> // body >>>> } >>>> >>>> _OR_ >>>> >>>> [Without block] >>>> function foo() { >>>> require(assert-expr, 'msg'); >>>> require(assert-expr, 'msg'); >>>> require(assert-expr, 'msg'); >>>> invariant(assert-expr, 'msg'); >>>> invariant(assert-expr, 'msg'); >>>> invariant(assert-expr, 'msg'); >>>> return(assert-expr, 'msg'); >>>> return(assert-expr, 'msg'); >>>> return(assert-expr, 'msg'); >>>> >>>> // function body >>>> } >>>> >>>> >>>> Currently, following code wouldn't work (PHP 7.0.0-dev) >>>> ---------- >>>> assert(function() {return FALSE;}, 'AAAAA'); >>>> ---------- >>>> >>>> For block version, which do you prefer, allow any PHP syntax or assert >>>> only? >>>> People may use anonymous function to do fancy jobs anyway if it's >>>> supported. >>>> >>>> No block version only accepts EXPR obviously, but anonymous function >>>> may >>>> be used with this as well. >>>> >>>> >>>> ============================================== >>>> Class invariants >>>> >>>> [With block] >>>> class Foo { >>>> __invariants() { >>>> assert(assert-expr, 'msg'); >>>> assert(assert-expr, 'msg'); >>>> assert(assert-expr, 'msg'); >>>> } >>>> } >>>> >>>> _OR_ >>>> >>>> [Without block] >>>> class Foo { >>>> __construct() { >>>> invariant(assert-expr, 'msg'); // Only allow in __construct()? >>>> Allowing invariant. >>>> invariant(assert-expr, 'msg'); >>>> invariant(assert-expr, 'msg'); >>>> } >>>> } >>>> >>>> >>>> ============================================== >>>> Global invariant >>>> >>>> I'm not sure if we should have >>>> >>>> function __invariants() { >>>> assert(assert-expr, 'msg'); >>>> assert(assert-expr, 'msg'); >>>> assert(assert-expr, 'msg'); >>>> } >>>> >>>> _OR_ >>>> >>>> invariant { >>>> assert(assert-expr, 'msg'); >>>> assert(assert-expr, 'msg'); >>>> assert(assert-expr, 'msg'); >>>> } >>>> >>>> to assert global vars, whole app state, etc. It may be useful for unit >>>> tests as well as app development. >>>> >>>> >>>> I'll start working after I get comment from you. >>>> >>>> Regards, >>>> >>>> -- >>>> Yasuo Ohgaki >>>> yohgaki@ohgaki.net >>>> >>> >>> >> >