Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82015
Return-Path: <dsp@php.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 67463 invoked from network); 6 Feb 2015 04:53:29 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 6 Feb 2015 04:53:29 -0000
X-Host-Fingerprint: 217.114.215.11 experimentalworks.net  
Date: Thu, 05 Feb 2015 23:53:28 -0500
Received: from [217.114.215.11] ([217.114.215.11:23684] helo=localhost.localdomain)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id AE/D4-45146-7C844D45 for <internals@lists.php.net>; Thu, 05 Feb 2015 23:53:28 -0500
To: internals@lists.php.net
References: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com>
User-Agent: slrn/pre1.0.0-18 (Linux)
Message-ID: <slrnmd8i73.775.dsp@dsp.local>
X-Posted-By: 217.114.215.11
Subject: Re: Design by Contract
From: dsp@php.net (David Soria Parra)

On 2015-02-05, Dmitry Stogov <dmitry@zend.com> wrote:
> --001a11c20e52da1ee0050e556679
> Content-Type: text/plain; charset=UTF-8
>
> Hi Yasuo,
>
> Following our conversation, I tried to imagine how DbC should look like in
> PHP from user perspective. Finally, I was influenced by the semantic
> proposed in D, and syntax proposed for Java. So, these are my initial
> thoughts:
>
> For php it may look like the following:
>
> function foo()
>     requre(<input-assert-expression>)
>     ensure(<output-assert-expression>)
> {
>   ...
> }
>
> It would require only one new reserved word "ensure".
>
> The assert expressions may be checked or not depending on ini directive.
> It should be also possible to prevent code generation for assertions (zero
> cost asserts). It was already implemented for
> https://wiki.php.net/rfc/expectations

I really like the idea. D allows complete blocks that then use assert. Might
be worht investigating why they went for a block rather than one expression.

> For inherited methods, only the self <input-assert-expression> should be
> checked, and all parent <output-asser-expression>. This is borrowed from D
> but not necessary to be repeated exactly.
>
> I think we shouldn't introduce "invariant" constraints for classes now. May
> be later.

I believe invariant is one of the strongest contract ideas as it goes well with
proper encapsluation and immutability like structures.