Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:82268 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 24012 invoked from network); 9 Feb 2015 11:19:17 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Feb 2015 11:19:17 -0000 Authentication-Results: pb1.pair.com smtp.mail=pthreads@pthreads.org; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=pthreads@pthreads.org; sender-id=unknown Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.192.171 cause and error) X-PHP-List-Original-Sender: pthreads@pthreads.org X-Host-Fingerprint: 209.85.192.171 mail-pd0-f171.google.com Received: from [209.85.192.171] ([209.85.192.171:38681] helo=mail-pd0-f171.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 96/BE-50460-4B798D45 for ; Mon, 09 Feb 2015 06:19:17 -0500 Received: by pdbft15 with SMTP id ft15so30487924pdb.5 for ; Mon, 09 Feb 2015 03:19:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FWHt06kOwnIk6/MLVmR3wKTT4LKb4fSd4HUxHgzuTmQ=; b=mKAEQzhfijd5uLQek6lVcJmFpogaphBvHQmgaxy+aHCC1s/GFMLsoVN0nPN6kL4QHg HcAKL1UEmS52Ukrh3Jj7X+QiNmxMLYYDoaznXIrEI0XtqZGbuYS9ag/0NSFRyA8DLMrB UBYYdk9r3fGRqmU4BbN2cWOBrzECk5EtSXQcajfwM2Hcg4wewUmLkDL+89PuNS51gQsE g79v/G5iQM3X1ztZKHCj/z/I8HFJTsbTr43R+9lQrHv22dRMAZmlIn+7bCeh5dDJw91W sGfnc6d0cGO6cPprLmOrR2KO1YlXRP8xOYSYjg9yihOkYCG1PpEu+92KQhLOkNvQ5fKx PY4Q== X-Gm-Message-State: ALoCoQmAts+aS7KgJ6PdfssIw7TjDBXH9EFFSHUdlazt3UHvrxCi0WaBX0m8iPy26C7lzkNjN36C MIME-Version: 1.0 X-Received: by 10.66.185.230 with SMTP id ff6mr28013834pac.102.1423480754101; Mon, 09 Feb 2015 03:19:14 -0800 (PST) Received: by 10.70.49.100 with HTTP; Mon, 9 Feb 2015 03:19:13 -0800 (PST) X-Originating-IP: [109.145.22.92] In-Reply-To: References: <54D7ED22.3080001@gmail.com> Date: Mon, 9 Feb 2015 11:19:13 +0000 Message-ID: To: Dmitry Stogov Cc: Yasuo Ohgaki , Stanislav Malyshev , PHP Internals Content-Type: multipart/alternative; boundary=001a1134259ab198f3050ea5f0b8 Subject: Re: [PHP-DEV] Design by Contract From: pthreads@pthreads.org (Joe Watkins) --001a1134259ab198f3050ea5f0b8 Content-Type: text/plain; charset=UTF-8 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 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 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 wrote: >> >>> Hi Dmitry and Joe, >>> >>> On Mon, Feb 9, 2015 at 6:01 PM, Dmitry Stogov 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 >>> >> >> > --001a1134259ab198f3050ea5f0b8--