Re: Design by Contract

Hi Robert, This is about "declarative" vs "imperative" programming. Also constraints may be enabled for debugging and completely disabled for production. I'm not the inventor of this approach, I just started to think about it myself :) You opinion makes sense as well. PHP doesn't have to support all the possible features. Thanks. Dmitry. On Thu, Feb 5, 2015 at 2:47 PM, Robert Stoll <php@tutteli.ch> wrote: > 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 > > >