Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82208
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.44 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <54D7ED22.3080001@gmail.com>
References: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com>
 <54D7ED22.3080001@gmail.com>
Date: Mon, 9 Feb 2015 10:22:29 +0900
Message-ID: <CAGa2bXZMmPTT=EgxKiXTbRhDJvd=6UfJ5jJrZwCRvFsnY-D=yQ@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Dmitry Stogov <dmitry@zend.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c2d274095b55050e9d9d2c
Subject: Re: [PHP-DEV] Design by Contract
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c2d274095b55050e9d9d2c
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Mon, Feb 9, 2015 at 8:11 AM, Stanislav Malyshev <smalyshev@gmail.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()
> >     requre(<input-assert-expression>)
> >     ensure(<output-assert-expression>)
> > {
> >   ...
> > }
>
> Why not do it simpler?
>
> function foo() {
> // require
> assert(<input-assert-expression>);
> ...
> // ensure
> assert(<output-assert-expression>);
> }
>
> I'm oversimplifying a bit, but in general, why we need more places to
> have code in the function than the actual code of the function? It would
> be harder to parse, to read, to maintain, to debug, to profile, etc. and
> I'm not sure what exactly it provides that can't be done by plain
> regular code inside the function.
>
> If we're concerned about the costs of assert, we could make special
> provision in the compiler for zero-cost asserts. It doesn't require
> moving code out of the function.


Interesting idea. I like it.
The only draw back I can see now is that this may make post/pre condition
retrieving
harder for automatic documentation.  We may think of solution for this.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c2d274095b55050e9d9d2c--