Hi Francois, On Fri, Feb 6, 2015 at 1:18 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> > On Fri, Feb 6, 2015 at 1:11 AM, François Laupretre <franc...@tekwire.net> > wrote: > >> > De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo >> Ohgaki >> >> > We don't have to integrate DbC into phpdoc. phpdoc may have integration >> of new DbC syntax. >> > I think it's helpful even if phpdoc copies post/pre condition as >> document. >> > >> > There are too many possibility for DbC syntax. >> > We are better to choose something in common among languages. >> >> No. The more I detail the concept, the more I read alternative proposals, >> the more I consider extending phpdoc is the best solution. As I explain in >> the RFC, both concepts are closely related, and that's the only solution >> I've seen so far that preserves BC. I could add that it proposes a solution >> to issues not even detected nor discussed in alternative proposals, like >> the syntax for return value, separate check for arguments returned by ref, >> built-in type checks, etc. Before we choose an alternative syntax, I think >> we should have good reasons, not 'Hey, that's how it's done in D !'. If >> there's a good reason to copy D or Eiffel syntax, let's adopt it, but I >> haven't read any good reason so far. And D is not so widely used so there's >> no user habit. We can copy the concept without copying the syntax. >> >> I think we're going too fast here. Before giving up and switching to >> another syntax, can you give me a little time to present what I have in >> mind. I started writing it yesterday evening and it will be ready >> tomorrow morning (UTC). Then, we can make a decision. >> > > I didn't notice you have updated the RFC sorry. Sure, I'll read it and > respond. > https://wiki.php.net/rfc/dbc Thank you for your time. It's based on annotation approach. This kind of implementation requires a lot of work... I have more simpler approach in my mind based on current PHP language not to invent new language. I'll use syntax something similar to Dmitry proposed. Let me explain my original thought. Since we have reserved __functionname(), __some_functioname() should not have BC issues. ---------------- function foo($param) require ( // Compiled as __require_foo($param) // Any PHP code is allowed and works just like PHP function. // Abuse is possible. Users have freedom shoot their own foot. assert('is_string($param'); if (strlen($param) > 100) { echo "String is more than 100\n"; return FALSE; // return value is ignored. } ) ensure ( // Compiled as __ensure_foo($__return_value) // Same as require. Any PHP code assert('is_int($__return_value)'); // $__return_value is the return value assert($__return_value > 0); ) invariant ( // Check conditions always true. It may be __invariant_foo() // Question is should this have foo() scope? // Same as require/ensure. Any PHP code. // invariant() exists not to repeat require()/ensure() ) // Function body { // BODY } ---------------------- Zend engine has 2 execute() - execute() - Just execute foo() - execute_dev() - Call functions as follows __require_foo($param) __invariant() foo() __invariant() __ensure_foo($__return_value) With this approach, parser and compiler needs little modification and execute_dev() can handle additional functions while execute() only executes foo(). execute_dev() is simple because it just calls plain PHP functions if they exists. Is there is syntax error or assertion error. Error messages look like PHP Warning: assert(): asdfasdf failed in __require_foo() on line 2 This is simple yet useful/easy to use/powerful/flexible/fast. Any checks can be done with PHP syntax. I think assert() should be used usually, though. I thought to use require{} rather than require() because {} seemed natural for function. This is my thought. It's almost D. I don't know about AST much, so AST may be better/easier than having 2 execute(). Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
