Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82340
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAJ26g5QT2545yKEEHD3hho_FAVzF+Vs5qsExtZqDO+RqDTZUjg@mail.gmail.com>
References: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com>
	<54D7ED22.3080001@gmail.com>
	<CA+9eiLvn7BzfG5N+5Oca8pVO1OTzN9=jWof6NrVDfxvvu-XqPA@mail.gmail.com>
	<CAL=_i_m78Zo5euReKsvFfrLknFq7KEzoNnrrBefC987u+=+yHQ@mail.gmail.com>
	<CA+9eiLuUFiKwOR-BqQEmkQirpAMxgb0GE70Zz7h4WDsd1Me8FQ@mail.gmail.com>
	<CAGa2bXYDvdvRLiOpDk8EnvE00JE4x47SXB9fET4uO2Er_F6s_w@mail.gmail.com>
	<CAL=_i_=mGc_0u0YDCQ7Jiqn_ggyJmQSd_mk_snf7ArDpDXO53A@mail.gmail.com>
	<CA+9eiLur0DVGBNkzFkiTj3POL5B9H0D8=5wE-wuwN2O-FQZNyg@mail.gmail.com>
	<CAL=_i_m=XDKtc2iCSjoquaHkmX862gyMweKS5Xw4AS--oLj19w@mail.gmail.com>
	<CA+9eiLsX=mOOgXmNBKD1L6WKx2=Vy81mThaKa1XCjjAw6R=2vA@mail.gmail.com>
	<CAGa2bXYYp0WQmnTnbsHXzc8XGG0PxOVHu7XvwiMCSJiUWoKeCg@mail.gmail.com>
	<CA+9eiLtj79MevMVg1cBSzGvfcdH=jszWym1Bf50zRsQ+94jp5w@mail.gmail.com>
	<CAGa2bXY6OO2svdcguHLEYxQ_XUHjssBjgwJ_Had+JPjFzbZ80g@mail.gmail.com>
	<CAJ26g5QT2545yKEEHD3hho_FAVzF+Vs5qsExtZqDO+RqDTZUjg@mail.gmail.com>
Date: Tue, 10 Feb 2015 11:21:19 +0400
Message-ID: <CA+9eiLu5TY=3zv8Zx+2q83pf+vviNc326S=WXXOGuwgVt=asUw@mail.gmail.com>
To: Patrick Schaaf <php@bof.de>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01538610ada9c0050eb6bb9f
Subject: Re: [PHP-DEV] Design by Contract
From: dmitry@zend.com (Dmitry Stogov)

--089e01538610ada9c0050eb6bb9f
Content-Type: text/plain; charset=UTF-8

On Tue, Feb 10, 2015 at 10:06 AM, Patrick Schaaf <php@bof.de> wrote:

> Am 10.02.2015 07:25 schrieb "Yasuo Ohgaki" <yohgaki@ohgaki.net>:
> >
> > https://wiki.php.net/rfc/dbc2
>
> First of all, thanks for your effort so far.
>
> Some questions, after reading the RFC, with no particular order:
>
> 1) Regarding invariants: those will be called for method calls on objects.
> What about static class methods? Could we have static class invariants
> (static require(.....))? Would these be called for both static and
> nonstatic method calls (nonstatic method calls can change static class
> state, too)
>
yeah, "static require()" may be a good addition. However, I don't like to
invite a bicycle, we are going to borrow most related semantic from D.

> 2) the pre- and postconditions could be useful for ordinary, non-OO
> functions, too, to check parameters, return, and global state invariants
>
any function will able to use contracts.

3) I think that method preconditions are not sufficient. Pretty often,
> public methods first sanitize and validate their input parameters, and
> rightly so. In these cases, it would be useful to have the checking, in the
> same general framework, at an arbitrary point in the function body. In
> other words, assert (with an expression as the first argument, instead of a
> string....).
>
assert() will work as well. Actually, all these addition require/return
syntax is going to be just a syntax sugar that will finally call assert()s
in proper order.

> 4) regarding the error message second argument to the condition
> definitions, it would be useful to have these not only as plain
> (extrapolated) strings, but as full expressions-that-evaluate-to-string.
> That would permit hooking to arbitrary private logging and log formatting
> methods.
>
I don't think we will implement this. It may be proposed later as a DbC
extension.

> 5) and a bit off-topic, it would be useful to be able to declare (sic)
> whole methods to be nonproduction only: Methods that will only be used in
> pre/post/invariant condition expresions (or error formatters a la my point
> 4)
>
this is also not directly related as well.
Sorry, but we should define realistic target to be able to provide a
working solution.
We can't think about all possible and indirectly related features at once.

Thanks. Dmitry.



> best regards
>   Patrick
>

--089e01538610ada9c0050eb6bb9f--