Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82316
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.52 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CA+9eiLsX=mOOgXmNBKD1L6WKx2=Vy81mThaKa1XCjjAw6R=2vA@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>
Date: Tue, 10 Feb 2015 05:19:37 +0900
Message-ID: <CAGa2bXYYp0WQmnTnbsHXzc8XGG0PxOVHu7XvwiMCSJiUWoKeCg@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: Joe Watkins <pthreads@pthreads.org>, Stanislav Malyshev <smalyshev@gmail.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c2f9b4ba0189050ead7f47
Subject: Re: [PHP-DEV] Design by Contract
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c2f9b4ba0189050ead7f47
Content-Type: text/plain; charset=UTF-8

Hi Dmitry and Joe,

On Mon, Feb 9, 2015 at 8:27 PM, Dmitry Stogov <dmitry@zend.com> wrote:

> yes. this may work.
> probably better to put it after extends and implements.
>
>
> Dmitry.
>
> On Mon, Feb 9, 2015 at 2:19 PM, Joe Watkins <pthreads@pthreads.org> wrote:
>
>> Could this be described as a requirement of the class ?
>>
>> class Mine
>>     require(invariant-expr)
>>     extends Something
>>     implements Someface {
>>
>>     public function method($param) : return
>>         require(input-expr),
>>         return(output-expr) {
>>
>>     }
>> }
>>
>> To avoid invariant keyword maybe.
>>
>
This would work.
If users have adopted DbC in some way, 'invariant' may be used already.

I see two issues.

Interface works, but most classes are class without interfaces. Then users
have to repeat
require()/return() many times to check class state or have to use interface
for DbC.

Since compiler does not know a method() is for DbC invariant, it will be
compiled and exists
in production execution.

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.

On place closure call like javascript is not supported in PHP, but function
works with assert.

<?php
function foo() { return FALSE; }
assert(foo());
?>
PHP Warning:  assert(): Assertion failed in - on line 3

This wouldn't be changed for require()/return()/invariant()?

We need a switch to change development/production. I'll use "dbc=On/Off"
for now.
If you have any better idea, please let me know. (dbc will be INI_SYSTEM)

For CLI, there will be no command line switch for dbc. It executes script
production mode by
default. If user needs development mode

php -d dbc=1 script.php

should be used.


And finally, are we going to allow custom assertion error message? e.g.

require($a > 0, 'Parameter $a must be positive number');

Since this contract is definition like "implements"/"extends", we may not
allow
custom error message. I'll write the RFC not to allow custom error messages
unless
you dislike it.

I think we have enough consensus/information to start writing the RFC.
If I have any concern, I'll ask here.

Regards,

P.S. If anyone finds issues with DbC as class definition, please let me
know.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c2f9b4ba0189050ead7f47--