Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:82331 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 4461 invoked from network); 10 Feb 2015 06:25:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Feb 2015 06:25:46 -0000 Authentication-Results: pb1.pair.com header.from=yohgaki@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=yohgaki@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.176 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.216.176 mail-qc0-f176.google.com Received: from [209.85.216.176] ([209.85.216.176:54671] helo=mail-qc0-f176.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id FE/95-47508-864A9D45 for ; Tue, 10 Feb 2015 01:25:45 -0500 Received: by mail-qc0-f176.google.com with SMTP id c9so27091667qcz.7 for ; Mon, 09 Feb 2015 22:25:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=KWxugIg3rsA5z6zLIlGNh1Xb1f+qAiJibi2nLxMR4kI=; b=FAHRvmkElRtcVJnzwfc5orONGn2/MKwXFxN9XkEBs6+GJ7l0AdmNbv9GRIpthM7iQj YDGU3lM3aD+YeVv7fAwecthfHJN1HETqNHStxzWzR7YE9XmKy5kBkO7c4USI+i/vd5T0 VFKxixmms1OedBQHhfWeXcxpeK3POx1PITEEHxyCCAtlMR6OFOyz/2YhuM02ZQyNpi7d 6hWi6+/eDN4/bPVFZLf8wnSCaPbz/a7m44+SWFYg08UlBeBLSfIqbN/dVTIhmngDRuzI KfUrL0MNPFQkjTlyRSDE28wSvekM4Lmsg7tRt/B6XH1D74llGSivoaxfAvpDgGztHR8/ znEw== X-Received: by 10.229.190.6 with SMTP id dg6mr50430005qcb.16.1423549541245; Mon, 09 Feb 2015 22:25:41 -0800 (PST) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.229.35.200 with HTTP; Mon, 9 Feb 2015 22:25:00 -0800 (PST) In-Reply-To: References: <54D7ED22.3080001@gmail.com> Date: Tue, 10 Feb 2015 15:25:00 +0900 X-Google-Sender-Auth: l4WdR3wC7LyIpEohWIyvlg5-Shw Message-ID: To: Dmitry Stogov Cc: PHP Internals , Stanislav Malyshev , Joe Watkins Content-Type: multipart/alternative; boundary=001a11336798b9e9dc050eb5f479 Subject: Re: [PHP-DEV] Design by Contract From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a11336798b9e9dc050eb5f479 Content-Type: text/plain; charset=UTF-8 Hi Dmitry, On Tue, Feb 10, 2015 at 1:43 PM, Dmitry Stogov wrote: > On Feb 9, 2015 11:20 PM, "Yasuo Ohgaki" wrote: > > > > Hi Dmitry and Joe, > > > > On Mon, Feb 9, 2015 at 8:27 PM, Dmitry Stogov wrote: > >> > >> 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. > > > > > > This would work. > > If users have adopted DbC in some way, 'invariant' may be used already. > > > > I see two issues. > > > > Interface works, but most classes are class without interfaces. Then > users have to repeat > > require()/return() many times to check class state or have to use > interface for DbC. > > > > In D classes may have "invariant" constraints. We may use "require" > keyword for it. The constraints ineritance rules and order of calls to > constrains must be the same s in D. > > class Foo { > private $sum = 0; > require($this->sum >= 0); // invariant constraint will be called > before and after every method > function add($n) { > $this->sum += $n; > } > } > OK. I'll update the RFC. > > Since compiler does not know a method() is for DbC invariant, it will be > compiled and exists > > in production execution. > > > > Use of interface: > > - no additional keyword (pros) > > - requires interface for DbC, most classes does not require interface > (cons) > > - if interface is not used, user has to repeat invariant conditions > over and over (cons) > > - requires to define method that should not exist in production (cons) > > I didn't understand you idea. > Joe's idea was to use Interface for invariant condition grouping. If we use your idea, issue is solved. class Foo { > private $sum = 0; > require($this->sum >= 0); // invariant constraint will be called > before and after every method > function add($n) { > $this->sum += $n; > } > } > Ok. > > > > New keyword: > > - does not require interface for efficient definition (pros). > > - new keyword (cons) > > > > It seems we are better to choose proper keyword for 'invariant'. > 'invariant' is not common, so 'invariant' > > may be good enough choice. Does anyone use 'invariant' as > function/method/class/constant names? > > If there is better name, suggestion is appreciated. > > > > On place closure call like javascript is not supported in PHP, but > function works with assert. > > > > > function foo() { return FALSE; } > > assert(foo()); > > ?> > > PHP Warning: assert(): Assertion failed in - on line 3 > > > > This wouldn't be changed for require()/return()/invariant()? > > > > We need a switch to change development/production. I'll use "dbc=On/Off" > for now. > > If you have any better idea, please let me know. (dbc will be INI_SYSTEM) > > Check the "expectations" RFC. I think, it's going to be 3 state switch, > zero-cost disable, run-time disable, run-time enable. So, it may be > INI_ALL, but it won't be possible to switch from/to zero-cost at run-time. > Ok. > > > > For CLI, there will be no command line switch for dbc. It executes > script production mode by > > default. If user needs development mode > > > > php -d dbc=1 script.php > > > > should be used. > > > > > > And finally, are we going to allow custom assertion error message? e.g. > > > > require($a > 0, 'Parameter $a must be positive number'); > > I think, it may be useful. > Ok. I'll use it. > > > > Since this contract is definition like "implements"/"extends", we may > not allow > > custom error message. I'll write the RFC not to allow custom error > messages unless > > you dislike it. > > > > I think we have enough consensus/information to start writing the RFC. > > If I have any concern, I'll ask here. > > Ok, go forward :) > Updated wiki page. https://wiki.php.net/rfc/dbc2 If you would like to change something, please let me know. I don't think finished draft at all and I don't mind going back and forth. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --001a11336798b9e9dc050eb5f479--