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 <[email protected]> wrote:
> Hi Dimitry
>
> > -----Ursprüngliche Nachricht-----
> > Von: Dmitry Stogov [mailto:[email protected]]
> > 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
>
>
>