Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82243
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54D7ED22.3080001@gmail.com>
References: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com>
	<54D7ED22.3080001@gmail.com>
Date: Mon, 9 Feb 2015 12:44:29 +0400
Message-ID: <CA+9eiLvn7BzfG5N+5Oca8pVO1OTzN9=jWof6NrVDfxvvu-XqPA@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec52d53ab4d5f49050ea3c75b
Subject: Re: [PHP-DEV] Design by Contract
From: dmitry@zend.com (Dmitry Stogov)

--bcaec52d53ab4d5f49050ea3c75b
Content-Type: text/plain; charset=UTF-8

It's nothing wrong here. It's just a concept that cares about constraints
definition more.

So, DbC with asserts spread among the code is like OOP without classes.

Thanks. Dmitry.


On Mon, Feb 9, 2015 at 2:11 AM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> > 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.
> --
> Stas Malyshev
> smalyshev@gmail.com
>

--bcaec52d53ab4d5f49050ea3c75b--