Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81904
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <006001d04139$8c1bd540$a4537fc0$@tutteli.ch>
References: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com>
	<006001d04139$8c1bd540$a4537fc0$@tutteli.ch>
Date: Thu, 5 Feb 2015 15:56:32 +0400
Message-ID: <CA+9eiLtCF=ETv+B4GFQ9TVcE+P6iPp3r7-3KX01jxM9Au-BRog@mail.gmail.com>
To: Robert Stoll <php@tutteli.ch>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01538610c7a6c4050e55fe3f
Subject: Re: [PHP-DEV] Design by Contract
From: dmitry@zend.com (Dmitry Stogov)

--089e01538610c7a6c4050e55fe3f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Robert,

This is about "declarative" vs "imperative" programming.
Also constraints may be enabled for debugging and completely disabled for
production.
I'm not the inventor of this approach, I just started to think about it
myself :)

You opinion makes sense as well. PHP doesn't have to support all the
possible features.

Thanks. Dmitry.


On Thu, Feb 5, 2015 at 2:47 PM, Robert Stoll <php@tutteli.ch> wrote:

> Hi Dimitry
>
> > -----Urspr=C3=BCngliche Nachricht-----
> > Von: Dmitry Stogov [mailto:dmitry@zend.com]
> > Gesendet: Donnerstag, 5. Februar 2015 12:14
> > An: Yasuo Ohgaki; PHP Internals
> > Betreff: [PHP-DEV] Design by Contract
> >
> > 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 b=
e
> 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.
>
> I am not sure if this new syntactic sugar really improves readability.
> What is the difference between the above and having something like?
>
> function foo($x, $y){
>   if(validateFoo($x, $y)){}
>
>   //do something
>   $result =3D 'some value';
>
>   if(postValidateFoo($result){
>     return $ result;
>   }
> }
>
> Actually putting everything in one function seems even worse from a singl=
e
> responsibility point of view. But I suppose I am missing something
> essential here.
>
> Cheers,
> Robert
>
>
>

--089e01538610c7a6c4050e55fe3f--