Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82221
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXZ8p8VibVoZtJ3fOsLbKbzoQ3Fn=5_=Supg_d1y5My4xQ@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> <CAGa2bXZ8p8VibVoZtJ3fOsLbKbzoQ3Fn=5_=Supg_d1y5My4xQ@mail.gmail.com>
Date: Sun, 8 Feb 2015 23:44:03 -0500
Message-ID: <CAFp73XsArH8SG5T2T7=HaAGUkvAz_P627iSibQfzeFtKyUcoOA@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Joe Watkins <krakjoe@php.net>, Stanislav Malyshev <smalyshev@gmail.com>, 
	Dmitry Stogov <dmitry@zend.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01184038addbf3050ea06cf8
Subject: Re: [PHP-DEV] Design by Contract
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

--089e01184038addbf3050ea06cf8
Content-Type: text/plain; charset=UTF-8

Hi Yasuo,

Class invariants could be done as this example:

class Foo {
    private function isValidState() {
        // Checks class's state and returns boolean
    }

    public function doSomething($args) {
        // Some complex operation over Foo instance using $args
        // then...

        assert $this->isValidState(): $this; // it would call
Foo::__toString() for AssertionError message
    }
}

Another example of pre and post conditions:

function foo($number) {
    // pre-condition
    assert is_numeric($number): '...';

    // Some expensive operation creating $value as response

    // post-condition
    assert someCheckWith($value): '...';
    return $value;
}

A good explanation about use-cases can be found here
http://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html#class-invariants

[]s,

On Sun, Feb 8, 2015 at 11:24 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> 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
>



-- 
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

--089e01184038addbf3050ea06cf8--