> 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 <yohg...@ohgaki.net> wrote: > Hi Dmitry and Joe, > > On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > >> On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov <dmi...@zend.com> 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 > yohg...@ohgaki.net > >
