Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82212
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXZMmPTT=EgxKiXTbRhDJvd=6UfJ5jJrZwCRvFsnY-D=yQ@mail.gmail.com>
References: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com>
 <54D7ED22.3080001@gmail.com> <CAGa2bXZMmPTT=EgxKiXTbRhDJvd=6UfJ5jJrZwCRvFsnY-D=yQ@mail.gmail.com>
Date: Sun, 8 Feb 2015 21:58:13 -0500
Message-ID: <CAFp73XuVGRbmUG=ZVecq8=Ms1dN5_SyG6Z1T3JcPoa32QsaY5Q@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, Dmitry Stogov <dmitry@zend.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11407bc42c9b59050e9ef2f2
Subject: Re: [PHP-DEV] Design by Contract
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

--001a11407bc42c9b59050e9ef2f2
Content-Type: text/plain; charset=UTF-8

Hi Yasuo,

Design by Contract could be used at the top of Annotation if (and only if)
it also had support for Interceptors. Since it could potentially be a
nightmare for PHP, I don't think it's time to propose something at the top
of another thing that is still far from being reality.
It would follow somehow a similar approach of what Symfony validators do:
http://symfony.com/doc/current/book/validation.html but it would be called
at possible 3 times: pre-execution, in-execution (using around and bound to
an external class) and post-execution.
However, I keep myself asking if this is a good idea. It obviously brings a
certain level of AOP to PHP, but I'd rather take a simplistic approach such
as the one suggested by Stas but with a few adjustments.
His approach is more inline to C and C++, but I like a more customizable
Java style assertion support
http://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html
Example:

function foo($name) {
    assert $name !== '': "Name must not be an empty value";
}

This would be similar to this:

function foo($name) {
    if ($name === null) {
        throw new AssertionError("Name must not be an empty value");
    }
}

Basically, new grammar to be supported would be something like this:

assert_statement:
    T_ASSERT expr ':' expr ';'
;

Where the first expr is a boolean expression and the second expr must
return a value (cannot be null).

This would be a good start for PHP, even though Java does not recommend to
use this for argument's method check (
http://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html#usage),
but I consider that since PHP is not a strict language, we do not have the
same privileges by automating this check form arguments itself.

That is my personal suggestion for DbC, which does not fully align with
what it was proposed, but since you asked... here it is.

[]s,


On Sun, Feb 8, 2015 at 8:22 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> 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
>



-- 
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

--001a11407bc42c9b59050e9ef2f2--