Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:82272 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 29954 invoked from network); 9 Feb 2015 11:27:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Feb 2015 11:27:46 -0000 Authentication-Results: pb1.pair.com header.from=dmitry@zend.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=dmitry@zend.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.176 as permitted sender) X-PHP-List-Original-Sender: dmitry@zend.com X-Host-Fingerprint: 209.85.220.176 mail-vc0-f176.google.com Received: from [209.85.220.176] ([209.85.220.176:59890] helo=mail-vc0-f176.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 97/00-50460-2B998D45 for ; Mon, 09 Feb 2015 06:27:46 -0500 Received: by mail-vc0-f176.google.com with SMTP id la4so784080vcb.7 for ; Mon, 09 Feb 2015 03:27:43 -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=4an+6ib/9gIoViEbsDf+TeW4XVMVoW3Lu9TNReOfJo8=; b=LI+AgIBNuAXsVDgF/xcEGkbPvDZfZtqNfWl2B0C4QQSC8QO4ULkT+nMWEW/CuZ0Gdf TVtc5Xi7sf3g+emd4kWDwOo+IAFtU+LAuZcTF5wfvVJOk/Vx5gBwGJokuwBvmCetzlrs ycioNLXXnbZVf4ehM45oC0Aitk+dfN3Dp1ysbXlvs2bG0M9PPLwlR1/mt4CBuVnmtsVU 41hYzbVh714ywZRVmYmQ1sd5evcChc3GbWacBAMsMh2JeCKNS+PNby9q8kOUiiivMR4v 5AlFAbhJsy6fQBJRxRoeCzE7w4TAqvuxgukSDcdPYC1evsSuHktVcFVqStCXA2vACFsi O4Yg== X-Gm-Message-State: ALoCoQlGLTPZh9ddyjLt27Q3RFozDcL8sWkN0xGvUJUe2oGV6ixW6FHvd4n4YHamm4iiKJNGfSN16sfIXAChspDxagaL3lN2hK3rYTwCP0pxdoKWFMn4n7l9Oo43XZLLjdcDJv7t3FxPajNvavCH1R99NtrgTrUMfQ== MIME-Version: 1.0 X-Received: by 10.221.18.136 with SMTP id qg8mr9759822vcb.27.1423481263843; Mon, 09 Feb 2015 03:27:43 -0800 (PST) Received: by 10.52.74.73 with HTTP; Mon, 9 Feb 2015 03:27:43 -0800 (PST) In-Reply-To: References: <54D7ED22.3080001@gmail.com> Date: Mon, 9 Feb 2015 15:27:43 +0400 Message-ID: To: Joe Watkins Cc: Yasuo Ohgaki , Stanislav Malyshev , PHP Internals Content-Type: multipart/alternative; boundary=001a113399e6138153050ea60f50 Subject: Re: [PHP-DEV] Design by Contract From: dmitry@zend.com (Dmitry Stogov) --001a113399e6138153050ea60f50 Content-Type: text/plain; charset=UTF-8 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 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 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 >>>> >>> >>> >> > --001a113399e6138153050ea60f50--