On Fri, Feb 6, 2015 at 2:01 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> 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.
>
I think it should not be a big problem extending parser to support
require/ensure syntax.
AST is going to be really helpful :)
Compilation is not going to be trivial but it's solvable.
> 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.
>
We may relay on assert() behavior. Depending on some setting it may emit
error or throw exception.
Thanks. Dmtiry.
>
> These are my random thoughts.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
>
