AW: [PHP-DEV] Design by Contract

From: Date: Thu, 05 Feb 2015 11:47:40 +0000
Subject: AW: [PHP-DEV] Design by Contract
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-81902@lists.php.net to get a copy of this message
Hi Dimitry > -----Ursprüngliche Nachricht----- > Von: Dmitry Stogov [mailto:dmitry@zend.com] > Gesendet: Donnerstag, 5. Februar 2015 12:14 > An: Yasuo Ohgaki; PHP Internals > Betreff: [PHP-DEV] Design by Contract > > Hi Yasuo, > > Following our conversation, I tried to imagine how DbC should look like in PHP from user > perspective. Finally, I was > influenced by the semantic proposed in D, and syntax proposed for Java. So, these are my > initial > thoughts: > > For php it may look like the following: > > function foo() > requre(<input-assert-expression>) > ensure(<output-assert-expression>) > { > ... > } > > It would require only one new reserved word "ensure". > > The assert expressions may be checked or not depending on ini directive. > It should be also possible to prevent code generation for assertions (zero cost asserts). It > was already implemented for > https://wiki.php.net/rfc/expectations > > For inherited methods, only the self <input-assert-expression> should be checked, and all > parent <output-asser- > expression>. This is borrowed from D but not necessary to be repeated exactly. > > I think we shouldn't introduce "invariant" constraints for classes now. May be > later. > > Implementation is going to generate code for input constraint after all RECV opcodes and before > code for function body, > and code for output constraint before RETURN opcode (may be reusing implementation of > "finally"). > > See: > http://dlang.org/contracts.html > http://jan.newmarch.name/java/contracts/paper-long.html > > Thanks. Dmitry. I am not sure if this new syntactic sugar really improves readability. What is the difference between the above and having something like? function foo($x, $y){ if(validateFoo($x, $y)){} //do something $result = 'some value'; if(postValidateFoo($result){ return $ result; } } Actually putting everything in one function seems even worse from a single responsibility point of view. But I suppose I am missing something essential here. Cheers, Robert

« previous php.internals (#81902) next »