Hi Dmitry,
On Fri, Feb 6, 2015 at 3:58 AM, Dmitry Stogov <dmi...@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
yohg...@ohgaki.net
