Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82330
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.220.54 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXZ8Wy7bUYgtbajr+GkpQtQEjQLMbFT2mSB5OEnLO2mgfg@mail.gmail.com>
References: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com>
	<54D7ED22.3080001@gmail.com>
	<CA+9eiLvn7BzfG5N+5Oca8pVO1OTzN9=jWof6NrVDfxvvu-XqPA@mail.gmail.com>
	<CAL=_i_m78Zo5euReKsvFfrLknFq7KEzoNnrrBefC987u+=+yHQ@mail.gmail.com>
	<CA+9eiLuUFiKwOR-BqQEmkQirpAMxgb0GE70Zz7h4WDsd1Me8FQ@mail.gmail.com>
	<CAGa2bXYDvdvRLiOpDk8EnvE00JE4x47SXB9fET4uO2Er_F6s_w@mail.gmail.com>
	<CAL=_i_=mGc_0u0YDCQ7Jiqn_ggyJmQSd_mk_snf7ArDpDXO53A@mail.gmail.com>
	<CA+9eiLur0DVGBNkzFkiTj3POL5B9H0D8=5wE-wuwN2O-FQZNyg@mail.gmail.com>
	<CAL=_i_m=XDKtc2iCSjoquaHkmX862gyMweKS5Xw4AS--oLj19w@mail.gmail.com>
	<CA+9eiLsX=mOOgXmNBKD1L6WKx2=Vy81mThaKa1XCjjAw6R=2vA@mail.gmail.com>
	<CAGa2bXYYp0WQmnTnbsHXzc8XGG0PxOVHu7XvwiMCSJiUWoKeCg@mail.gmail.com>
	<CAGa2bXbKs8cGRTQ1sfeRonnmVXtp7ftVDkz_ALmqr8OnczQxCg@mail.gmail.com>
	<CAGa2bXZ8Wy7bUYgtbajr+GkpQtQEjQLMbFT2mSB5OEnLO2mgfg@mail.gmail.com>
Date: Tue, 10 Feb 2015 06:16:03 +0000
Message-ID: <CAL=_i_kypYpa3t06peRKwtww=cbh+KhM+iAOtotDGNaFfJBuVA@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Dmitry Stogov <dmitry@zend.com>, =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@tekwire.net>, 
	Stanislav Malyshev <smalyshev@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c222ea56204f050eb5d2a7
Subject: Re: [PHP-DEV] Design by Contract
From: pthreads@pthreads.org (Joe Watkins)

--001a11c222ea56204f050eb5d2a7
Content-Type: text/plain; charset=UTF-8

Morning,

A good start ... ish ...

Please steer clear of using the assert API, and in so doing avoid BC
concerns with the current assert API.

Please avoid adding a magic method and use the suggested syntax for
invariant.

class Some {
    require(invariant-expr);

    /* ... */
}

like that is best I think ...

You need to explain how invariants are going to be inherited and executed
in detail.

Keep statements such as

> With proper use of DbC concept, it is known *programs to be more robust,
secure and faster*

Out of the RFC, since that cannot possibly be true and is just going to
cause people to argue about that point when it's extremely unimportant.

Cheers
Joe

On Mon, Feb 9, 2015 at 11:47 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi all,
>
> On Tue, Feb 10, 2015 at 5:27 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>
>> On Tue, Feb 10, 2015 at 5:19 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>>
>>> Use of interface:
>>>   - no additional keyword (pros)
>>>   - requires interface for DbC, most classes does not require interface
>>> (cons)
>>>   - if interface is not used, user has to repeat invariant conditions
>>> over and over (cons)
>>>   - requires to define method that should not exist in production (cons)
>>>
>>> New keyword:
>>>   - does not require interface for efficient definition (pros).
>>>   - new keyword (cons)
>>>
>>> It seems we are better to choose proper keyword for 'invariant'.
>>> 'invariant' is not common, so 'invariant'
>>> may be good enough choice. Does anyone use 'invariant' as
>>> function/method/class/constant names?
>>> If there is better name, suggestion is appreciated.
>>>
>>
>> It might be be better to use special method. No keyword, use only
>> reserved method name __func().
>> I'll write what I think that are better for PHP in the RFC.
>> We may discuss anything here to complete the RFC.
>>
>
> The RFC draft is ready.
> https://wiki.php.net/rfc/dbc2
>
> I think we might be better to use
>
> return($ret) {
>   assert($ret > 0);
> }
>
> as the syntax. It doesn't look like definition, but code though.
>
> We may introduce $> or like as return value, but it looks like PERL.
> It's not for me, but PHP stands for People Hate Perl for some.
>
> Any comments, corrections, improvements are appreciated.
> If anyone could fix bad English, it would be great!
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>

--001a11c222ea56204f050eb5d2a7--