Re: Design by Contract

Hi Dmitry, On Fri, Feb 6, 2015 at 3:58 AM, Dmitry Stogov <dmitry@zend.com> wrote: > I don't think we should chose "right" approach right now. > It's better to collect few possible solutions e.g. statements, > expressions, doc-comments, attributes... > then describe their pros and cons to select the best one > I agree. ensure($ret) {} is better than my original thought. I don't object to restrict pre/post conditions to expressions. require(is_numeric($a) && $a >= 0, "some error message") require(is_numerc($b) && $b >= 0, "another error message") this requires less lines and meaning is clear. For parsers other than PHP require { assert(is_numeric($a) && $a >= 0, "some error message") assert(is_numerc($b) && $b >= 0, "another error message") } may be a little easy to parse. Even if it is, it's marginal. Allowing any PHP syntax would require other parsers complex parsing. Those who would like to get pre/post conditions, it's time to think how it looks like including reflection. Restricting pre/post conditions to assert expressions may yield clean result. AST would be handy. Reflection is not too important, since pre/post conditions are for development. It may be okay to reflect existence of pre/post conditions. These conditions does not exists in production anyway. I'm not sure it's worth to support reflection. Rather than reflection, user space AST browser could be more useful. IMHO, E_WARNING is good enough. If anyone would like to 'throw' exceptions, it's time to think, too. These are my random thoughts. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net