Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81898
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.182 as permitted sender)
MIME-Version: 1.0
Date: Thu, 5 Feb 2015 15:14:04 +0400
Message-ID: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c20e52da1ee0050e556679
Subject: Design by Contract
From: dmitry@zend.com (Dmitry Stogov)

--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

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.

Implementation is going to generate code for input constraint after all
RECV opcodes and before code for function body, and code for output
constraint before RETURN opcode (may be reusing implementation of
"finally").

See:
http://dlang.org/contracts.html
http://jan.newmarch.name/java/contracts/paper-long.html

Thanks. Dmitry.

--001a11c20e52da1ee0050e556679--