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 <p...@tutteli.ch> wrote: > Hi Dimitry > > > -----Ursprüngliche Nachricht----- > > Von: Dmitry Stogov [mailto:dmi...@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 > > >
