Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82029
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXbH8UG9feFwG0J=HY0Gx7CC3rn-JBfDGJyhgLGVjVMpng@mail.gmail.com>
References: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com>
	<01d601d04146$6fbda4c0$4f38ee40$@tekwire.net>
	<CA+9eiLvQroYuUW_dVr+r5c=O=1aQ3upfahVUd1e-9qpLQRrxUw@mail.gmail.com>
	<020c01d0414b$2c3a1120$84ae3360$@tekwire.net>
	<CAEZPtU41ud0JSzfc6axnzdKCNJ48-LBCx=zuiFVpQ1mNdTK-kA@mail.gmail.com>
	<CAGa2bXZcTGdB6=iTJxnfkCm6dkUa=dHrsGKcofG3pSTftafRzg@mail.gmail.com>
	<023201d0415e$5731d800$05958800$@tekwire.net>
	<CAGa2bXZYvt5U644Q7+_Tr9o7=1X9svWK8OQEK4s06js9GGngyA@mail.gmail.com>
	<CAGa2bXYQotZvbrn0Zj_VM8FOs_HU16kyuWggStSJ38a7fRR7CQ@mail.gmail.com>
	<CA+9eiLtD2o3FVQJwS9TrVfRCy9H4YtJG3fubq+KBwVPXZ+wjWg@mail.gmail.com>
	<CAGa2bXbH8UG9feFwG0J=HY0Gx7CC3rn-JBfDGJyhgLGVjVMpng@mail.gmail.com>
Date: Fri, 6 Feb 2015 13:34:29 +0400
Message-ID: <CA+9eiLvF59E1ctOUC8RvQ-yVgzRw5qSuWH8V0WOyBAeqQN5cwA@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@tekwire.net>, 
	Pierre Joye <pierre.php@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1133e2c69b11ec050e6820be
Subject: Re: [PHP-DEV] Design by Contract
From: dmitry@zend.com (Dmitry Stogov)

--001a1133e2c69b11ec050e6820be
Content-Type: text/plain; charset=UTF-8

On Fri, Feb 6, 2015 at 2:01 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> 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.
>

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
> yohgaki@ohgaki.net
>
>

--001a1133e2c69b11ec050e6820be--