Hi Yasuo, Design by Contract could be used at the top of Annotation if (and only if) it also had support for Interceptors. Since it could potentially be a nightmare for PHP, I don't think it's time to propose something at the top of another thing that is still far from being reality. It would follow somehow a similar approach of what Symfony validators do: http://symfony.com/doc/current/book/validation.html but it would be called at possible 3 times: pre-execution, in-execution (using around and bound to an external class) and post-execution. However, I keep myself asking if this is a good idea. It obviously brings a certain level of AOP to PHP, but I'd rather take a simplistic approach such as the one suggested by Stas but with a few adjustments. His approach is more inline to C and C++, but I like a more customizable Java style assertion support http://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html Example:
function foo($name) { assert $name !== '': "Name must not be an empty value"; } This would be similar to this: function foo($name) { if ($name === null) { throw new AssertionError("Name must not be an empty value"); } } Basically, new grammar to be supported would be something like this: assert_statement: T_ASSERT expr ':' expr ';' ; Where the first expr is a boolean expression and the second expr must return a value (cannot be null). This would be a good start for PHP, even though Java does not recommend to use this for argument's method check ( http://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html#usage), but I consider that since PHP is not a strict language, we do not have the same privileges by automating this check form arguments itself. That is my personal suggestion for DbC, which does not fully align with what it was proposed, but since you asked... here it is. []s, On Sun, Feb 8, 2015 at 8:22 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > Hi Stas, > > On Mon, Feb 9, 2015 at 8:11 AM, Stanislav Malyshev <smalys...@gmail.com> > wrote: > > > > 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>) > > > { > > > ... > > > } > > > > Why not do it simpler? > > > > function foo() { > > // require > > assert(<input-assert-expression>); > > ... > > // ensure > > assert(<output-assert-expression>); > > } > > > > I'm oversimplifying a bit, but in general, why we need more places to > > have code in the function than the actual code of the function? It would > > be harder to parse, to read, to maintain, to debug, to profile, etc. and > > I'm not sure what exactly it provides that can't be done by plain > > regular code inside the function. > > > > If we're concerned about the costs of assert, we could make special > > provision in the compiler for zero-cost asserts. It doesn't require > > moving code out of the function. > > > Interesting idea. I like it. > The only draw back I can see now is that this may make post/pre condition > retrieving > harder for automatic documentation. We may think of solution for this. > > Regards, > > -- > Yasuo Ohgaki > yohg...@ohgaki.net > -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada