Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:82337 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 20534 invoked from network); 10 Feb 2015 07:05:57 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Feb 2015 07:05:57 -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.179 as permitted sender) X-PHP-List-Original-Sender: dmitry@zend.com X-Host-Fingerprint: 209.85.220.179 mail-vc0-f179.google.com Received: from [209.85.220.179] ([209.85.220.179:51415] helo=mail-vc0-f179.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 68/48-47508-3DDA9D45 for ; Tue, 10 Feb 2015 02:05:56 -0500 Received: by mail-vc0-f179.google.com with SMTP id hy4so4107803vcb.10 for ; Mon, 09 Feb 2015 23:05:53 -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=p1P3I6E+c16IRRncEu9RMmgLXtW6lq9H9bHMePr0JTw=; b=EaRi2FS6MtOskk+DQdyKtTnTMV0CHxF+S/BC7Pr4D+0tsqKtIgxA42WoWH7VFL6wK5 VeOA1dMpGGF+jxbcO/UDUCCNGGA31INgw4CwkPKosLNTe8GKD+6j7VysVzk+nBeYkRaO sDVIiVTRPu2bjF4dlFcXwHYNS0omzhtODQzyrA5vPuo2y3I7gm+S8sBoQiITpna6Z40Q aqKIGBQBM5IZxXK3qY/FUcAiSWoVpC3LymdzU7A7gvJ72gU7lTSvr06oATUJCscBSV6k 205ZrzpizxPE8TaULjxvXveitmSiweFf5gQVO4B5+vmseJI6Flcs6kcxKNYeZFYGVWBo 36LQ== X-Gm-Message-State: ALoCoQmbu4bpbN30nbSFAYaozpXe9ETA1chZmgnKxOEW4umluPQ3TKHZ42x6ovbLUq9Otd14+Mia0JmeoQR9WmUXfyd2cG+N3q8tBDWq1YN64lj5gZhnI3TiURTuPqSp/iMW2NUw0cPNNvS/t8tDe0sx5Gz+T8/6eA== MIME-Version: 1.0 X-Received: by 10.221.44.65 with SMTP id uf1mr13542939vcb.46.1423551953340; Mon, 09 Feb 2015 23:05:53 -0800 (PST) Received: by 10.52.74.73 with HTTP; Mon, 9 Feb 2015 23:05:53 -0800 (PST) In-Reply-To: References: <54D7ED22.3080001@gmail.com> Date: Tue, 10 Feb 2015 11:05:53 +0400 Message-ID: To: Joe Watkins Cc: Yasuo Ohgaki , PHP Internals , Stanislav Malyshev Content-Type: multipart/alternative; boundary=001a11c3ea3c7fa3f5050eb6841d Subject: Re: [PHP-DEV] Design by Contract From: dmitry@zend.com (Dmitry Stogov) --001a11c3ea3c7fa3f5050eb6841d Content-Type: text/plain; charset=UTF-8 good point, but I think we can do nothing about that. Anyway, it should be reflected in RFC. Dmitry. On Tue, Feb 10, 2015 at 9:59 AM, Joe Watkins wrote: > I'm not sure we can always enforce invariant contracts ... > > Evaluating invariant expressions on entry and exit is not enough, since a > property can be changed without the use of a method. > > Can or should, we do anything about that ? > > This should also be covered in the RFC, I think. > > Cheers > Joe > > On Tue, Feb 10, 2015 at 6:49 AM, Dmitry Stogov wrote: > >> Hi, >> >> can I make some minor correction? >> >> Thanks. Dmitry. >> >> >> >> On Tue, Feb 10, 2015 at 9:25 AM, Yasuo Ohgaki wrote: >> >>> 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 >>> >> >> > --001a11c3ea3c7fa3f5050eb6841d--