Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81971
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.182 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CA+9eiLtD2o3FVQJwS9TrVfRCy9H4YtJG3fubq+KBwVPXZ+wjWg@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>
Date: Fri, 6 Feb 2015 08:01:08 +0900
Message-ID: <CAGa2bXbH8UG9feFwG0J=HY0Gx7CC3rn-JBfDGJyhgLGVjVMpng@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
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=001a11c2cc9a04a112050e5f4aac
Subject: Re: [PHP-DEV] Design by Contract
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c2cc9a04a112050e5f4aac
Content-Type: text/plain; charset=UTF-8

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

--001a11c2cc9a04a112050e5f4aac--