AW: [PHP-DEV] Design by Contract
| From: | Robert Stoll | 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