Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:82419 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 20998 invoked from network); 11 Feb 2015 06:38:55 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Feb 2015 06:38:55 -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.169 cause and error) X-PHP-List-Original-Sender: pthreads@pthreads.org X-Host-Fingerprint: 209.85.192.169 mail-pd0-f169.google.com Received: from [209.85.192.169] ([209.85.192.169:42787] helo=mail-pd0-f169.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 02/A3-33902-DF8FAD45 for ; Wed, 11 Feb 2015 01:38:54 -0500 Received: by pdbfp1 with SMTP id fp1so2399985pdb.9 for ; Tue, 10 Feb 2015 22:38:50 -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=fWzz7Cp4DiXkTzvV+CIoiha/F2pxs4B+aUj0H/sJH7I=; b=l3lZP3oK4VCAIRxmNQxRaOnb4iFywmcXcTzIb5r/glk6SzKYjv71u4d5B1axFZo7m/ M+NIBsE7YfmoXENUjS+xu+aWYdZVW7k1GiadYq7eiI3OW0+W9JVrGkw9FDuEymMeTVu2 uvrANZhG9JIjD3NgZCpBfM6265rFEZ6DX3vOjOny1kFkj8zc1+szV9UwGcsGpam2X6Oe 5timxZyje7HlJCRXWjM70RmPJrMQlDFMK+lXW9oXNPBA9vLuGBoYNSGNvDueKRFdQzrW jGxN7V+XkYnud5OIU4mpUmcUNTNFyYH7F51NvfIONqi/AQytJu1S0Hz6c1PTSbvCaFdU 2sYQ== X-Gm-Message-State: ALoCoQnX6CgMwVOd2wLN1NXQ7fuisgPR0UsZOCM6E2DhDqP27YUsvVfbzYoBwhFq9au71Bs2U9jM MIME-Version: 1.0 X-Received: by 10.70.102.131 with SMTP id fo3mr44421325pdb.78.1423636730514; Tue, 10 Feb 2015 22:38:50 -0800 (PST) Received: by 10.70.49.100 with HTTP; Tue, 10 Feb 2015 22:38:50 -0800 (PST) X-Originating-IP: [109.145.22.92] In-Reply-To: References: <54D7ED22.3080001@gmail.com> Date: Wed, 11 Feb 2015 06:38:50 +0000 Message-ID: To: Yasuo Ohgaki Cc: Dmitry Stogov , Patrick Schaaf , internals Content-Type: multipart/alternative; boundary=001a11c30bd09ca5ff050eca4141 Subject: Re: [PHP-DEV] Design by Contract From: pthreads@pthreads.org (Joe Watkins) --001a11c30bd09ca5ff050eca4141 Content-Type: text/plain; charset=UTF-8 > We have related issue like how internal module incorporate with DbC. However these could be future issues. I think this should be an additional RFC, so we'll put this under future issues I think. > A little more clarification, following interface definition is allowed or not? Currently, we're saying that abstract functions (and interface functions) may not use contracts. Since interface methods are abstract functions, and abstract functions do no have a body, it doesn't seem to make sense to allow them to use contracts. The contracts are supposed to purtain to the body of the function, or the body of all functions in a class in the case of invariants: No body, no contracts. I'll make this clear ... I'll work a bit more on the RFC today ... Cheers Joe On Wed, Feb 11, 2015 at 3:01 AM, Yasuo Ohgaki wrote: > Hi Dmitry and Joe, > > On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki wrote: > >> On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov wrote: >> >>> You are welcome to edit https://wiki.php.net/rfc/dbc2 >>> It looks like we have similar views, so just make it better in a way you >>> think. >>> >> >> Looks good to me. It's much better than original. Thank you folks. >> We have related issue like how internal module incorporate with DbC. >> However >> these could be future issues. >> > > I would like explain one of the reason why I bring up internal module. > > http://php.net/manual/en/class.sessionhandlerinterface.php > > Session has internal interface definitions like > > SessionHandlerInterface { > /* Methods */ > abstract public bool close ( void ) > abstract public bool destroy ( string $session_id ) > abstract public bool gc ( string $maxlifetime ) > abstract public bool open ( string $save_path , string $name ) > abstract public string read ( string $session_id ) > abstract public bool write ( string $session_id , string $session_data ) > } > > but it should be like follows to be precise. > > SessionHandlerInterface { > /* Methods */ > abstract public bool close ( void ) > return($ret, is_bool($ret)); > > abstract public bool destroy ( string $session_id ) > require(strlen($session_id) > 0) > return($ret, is_bool($ret)); > > abstract public bool gc ( string $maxlifetime ) > require($maxlifetime >= 0) > return($ret, is_int($ret) && $ret >= -1); > > abstract public bool open ( string $save_path , string $name ) > require(is_string($save_path)) > require(is_string($name)); > return($ret, is_bool($ret)); > > abstract public string read ( string $session_id ) > require(strlen($session_id) > 0) > return($ret, is_bool($ret) || is_string($ret)); > > abstract public bool write ( string $session_id , string $session_data ) > require(is_string($session_id) && strlen($session_id) > 0) > require(is_string($session_data)) > return($ret, is_bool($ret)); > } > > This definition is more user friendly. There were too many user save > handlers > that do not return proper values because of current interface limitation. > > Scalar type and return type hint helps, but it does not cover > > return($ret, is_int($ret) && $ret >= -1); > > for example. > > If you think this is easy to implement and should be in the RFC, I would > appreciated it > and use it to raise assertion errors just like user class/interface. > > BTW, these restrictions are coded as error in current session module and > should > be checked by the module always. It's not mandatory for the RFC, but just > a missing piece. > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net > > --001a11c30bd09ca5ff050eca4141--