Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81932
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.53 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com>
References: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com>
Date: Thu, 5 Feb 2015 23:55:00 +0900
Message-ID: <CAGa2bXZ7XSs3OeE8qBrfZTUqJD2epnPxXq=86Gn52_5gY11fJg@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bdc19ac5e8e8b050e587fc7
Subject: Re: Design by Contract
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--047d7bdc19ac5e8e8b050e587fc7
Content-Type: text/plain; charset=UTF-8

Hi Dmitry,

Thank you for your time!

On Thu, Feb 5, 2015 at 8:14 PM, Dmitry Stogov <dmitry@zend.com> wrote:

> 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()
>     require(<input-assert-expression>)
>     ensure(<output-assert-expression>)
> {
>   ...
> }
>
> It would require only one new reserved word "ensure".
>

Less reserved word is better.


>
> 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").
>

It seems fine to me overall.
I have a few questions, but I think it's better to handle discussion as I
promised.
I'll ask later!

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--047d7bdc19ac5e8e8b050e587fc7--