Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82220
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.48 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAFp73XuVGRbmUG=ZVecq8=Ms1dN5_SyG6Z1T3JcPoa32QsaY5Q@mail.gmail.com>
References: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com>
 <54D7ED22.3080001@gmail.com> <CAGa2bXZMmPTT=EgxKiXTbRhDJvd=6UfJ5jJrZwCRvFsnY-D=yQ@mail.gmail.com>
 <CAFp73XuVGRbmUG=ZVecq8=Ms1dN5_SyG6Z1T3JcPoa32QsaY5Q@mail.gmail.com>
Date: Mon, 9 Feb 2015 13:24:50 +0900
Message-ID: <CAGa2bXZ8p8VibVoZtJ3fOsLbKbzoQ3Fn=5_=Supg_d1y5My4xQ@mail.gmail.com>
To: "guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com>, Joe Watkins <krakjoe@php.net>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, Dmitry Stogov <dmitry@zend.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c12f8c1e73fe050ea0294f
Subject: Re: [PHP-DEV] Design by Contract
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c12f8c1e73fe050ea0294f
Content-Type: text/plain; charset=UTF-8

Hi Guilherme,

On Mon, Feb 9, 2015 at 11:58 AM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:

> 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.
>

Thank you.
Since assert is going to have zero performance penalty, Stas proposal would
work.
We have to think of how invariants should be.

Joe, could you add "Proposal" section to the RFC.
https://wiki.php.net/rfc/expectations
Currently, it does not have "Proposal" section and it's harder to
understand what the
RFC is. Then, could you start vote? New assert is valuable regardless of
DbC.

The RFC will encourage users to use assert(), my little concern with Stas's
proposal
is misuse/abuse of assert(). Stas's proposal is simplest, but I'm not sure
if we should go
for it or not.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c12f8c1e73fe050ea0294f--